FWIW, I'm with Karl on this. This way you can leave the SNAPSHOT version mostly unchanged for longer periods of time which is great for CI builds or when you always want to test against the latest version. If you base the current SNAPSHOTs on the micro versions then its a bit more work to keep track of them after each release.
Either way, the OSGi versioning issue is avoided. Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Felix :: http://felix.apache.org Apache Directory Server :: http://directory.apache.org On Tue, Feb 9, 2010 at 1:09 PM, Karl Pauls <karlpa...@gmail.com> wrote: > On Tue, Feb 9, 2010 at 8:27 PM, Felix Meschberger <fmesc...@gmail.com> > wrote: > > Hi, > > > > On 09.02.2010 20:13, Karl Pauls wrote: > >> On Tue, Feb 9, 2010 at 7:41 PM, Felix Meschberger <fmesc...@gmail.com> > wrote: > >>> +1 > >>> > >>> It looks like the framework and bundlerepository do not follow our > >>> convention of using even release numbers (not a big issue and certainly > >>> not a showstopper), but something to care for the next releases to > come. > >> > >> Do we have the convention for micro releases too? We never followed > >> that for any release I did... Only for minor release numbers its the > >> odd/even game but not for micro releases no? > > > > The point is that discrepancy between Maven's version number > > interpreation of x.y.z-SNAPSHOT and OSGi's interpretation of the > > converted number x.y.z.SNAPSHOT. In Maven the SNAPSHOT version is > > "lower" than the x.y.z release version. In OSGi the SNAPSHOT version is > > higher. > > > > Therefore we started a convetion of having odd SNAPSHOTs (like > > 1.4.3-SNAPSHOT) and even releases (like 1.4.4) to ensure proper > > linearity. I initially proposed this for micro version only, Richard > > extended this to minor versions. > > > > To me it is mostly important, that the release version is higher than a > > SNAPSHOT version in OSGi understanding... > > Well, right, but that is why we as of now did it a little different > for the framework. We develop against 2.1.0-SNAPSHOT at the moment. > That will not be released but become 2.2.0 (or higher). If we along > the way see the need to make a micro release we do one but that should > be lower as the 2.1.0-SNAPSHOT and we never had a 2.0.3-SNAPSHOT. In > other words we have 2.0.2 < 2.0.3 < 2.1.0-SNAPSHOT < 2.2. I think that > is correct as well - it would be different if we had a 2.0.3-SNAPSHOT > at one point in time but as we didn't we don't have a problem, no? > > regards, > > Karl > > > Regards > > Felix > > > >> > >> regards, > >> > >> Karl > >> > >>> Regards > >>> Felix > >>> > >>> On 07.02.2010 22:30, Karl Pauls wrote: > >>>> I would like to call a vote on the following subproject releases: > >>>> > >>>> shell 1.4.2 > >>>> bundlerepository 1.4.3 > >>>> framework 2.0.3 > >>>> framework.security 1.0.0 > >>>> main 2.0.3 > >>>> > >>>> Staging repository: > >>>> > https://repository.apache.org/content/repositories/orgapachefelix-001/ > >>>> > >>>> You can use this UNIX script to download the release and verify the > signatures: > >>>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh > >>>> > >>>> Usage: > >>>> sh check_staged_release.sh 001 /tmp/felix-staging > >>>> > >>>> Please vote to approve this release: > >>>> > >>>> [ ] +1 Approve the release > >>>> [ ] -1 Veto the release (please provide specific comments) > >>>> > >>> > >> > >> > >> > > > > > > -- > Karl Pauls > karlpa...@gmail.com >
