Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] Re: Version Class changes and the Manifest file
The Plug-in Versioning Guidelines may be useful as a reference - http://wiki.eclipse.org/index.php/Version_Numbering. 

Neil

Tom Ware wrote:

I guess we need to figure out if we would ever need 4 or more digits.

Eric Gwin wrote:
Point taken, and I agree there could be confusion (though 1.1.1 would look like 1.1.1.2991-SNAPSHOT or 1.1.1.3267 (release)).
Therefore we should ALWAYS specify all the digits in our version. If we are going to use a three number versioning scheme (major).(minor).(bugfix), then we should always display the full version. 

ie. 1.1.0.2984 and 1.1.1.3267

-Eric

Tom Ware wrote:

I am concerned that will cause confusion at release time.
If we're not careful, it may look like we just released version 1.1.2984. If at some point, we release version 1.1.1, it will look like version 1.1.2984 is more recent, when in fact it is less recent. 

Are these changes just for manifest files, or also for jar file naming?

-Tom

Eric Gwin wrote:

Sounds like Option 4:
-----------------------
It does distinguish revision from the version. Though I put the period in because it blends it all into a single "Version Number". 

-Eric

Tom Ware wrote:
In your proposed solution, can we change the last "." to some other character 

e.g.
1.1-2312-SNAPSHOT


Eric Gwin wrote:
Seems to be little interest on the topic, but I need to at least pass this by the group so I'd like a vote today.
I'll put a +1 next to my choice. If there are no other votes, I guess it'll win by default.
As an aside, MW currently uses something completely different. I plan on setting this up to be consistent across EclipseLink 


"Implementation-Version" in the manifest:
_Option 1:_
(version)(type)-(date).(revision) or (version)-(date).(revision)
1.1SNAPSHOT-20081006.2312
1.1M3-20081029.2739
1.1-20081125.2984

_Option 2:_
(version).(type).(revision) or (version).(date).(revision)
1.1.20081006.2312
1.1.M3.2739
1.1.20081125.2984

_Option 3 (+1):_
(version).(revision)-(type) or (version).(revision)
1.1.2312-SNAPSHOT
1.1.2739-M3
1.1.2984
The first option results in a string closest to what we currently use (but with the addition of the revision).
The second is the result of minimally changing the build methodology.
The third makes the most sense to me. It gives the version and a unique build identifier (revision), is clean and easy to on the eyes, yet still has distinctions for nightly, milestone and release builds. However it diverges significantly from what we currently use. 

Thanks.

-Eric
------------------------------------------------------------------------ 

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev


_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev


_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

Back to the top