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

[Eric Gwin <eric.gwin@xxxxxxxxxx>]

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