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

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?


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".


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


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)

_Option 2:_
(version).(type).(revision) or (version).(date).(revision)

_Option 3 (+1):_
(version).(revision)-(type) or (version).(revision)

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.




eclipselink-dev mailing list
eclipselink-dev mailing list

eclipselink-dev mailing list

Back to the top