Re: [eclipselink-dev] Re: Version Class changes and the Manifest file

[Tom Ware <tom.ware@xxxxxxxxxx>]

Eric and I just had a chat and we have a slightly revised suggestion (based on 
option 3):


(version).r(revision)-(type) or (version).(revision)
where version is: (major).(minor).(patch)

1.1.0.r2312-SNAPSHOT
1.1.0.r2739-M3
1.1.0.r2984

-Tom


Neil Hauge wrote:
> 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
>
> _______________________________________________
> eclipselink-dev mailing list
> eclipselink-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev