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

Out of these options I like #3.
 
However, I would prefer if the snapshots had a date on them.  I don't think a date is necessary on the Milestones or releases
-----Original Message-----
From: Eric Gwin [mailto:eric.gwin@xxxxxxxxxx]
Sent: Monday, October 06, 2008 2:53 PM
To: Dev mailing list for Eclipse Persistence Services
Subject: Re: [eclipselink-dev] Re: Version Class changes and the Manifest file

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


Back to the top