On Tue, Feb 9, 2010 at 9: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?
Don't get me wrong, I'm not saying that we shouldn't change this approach and if we really voted on this in the past then I'm sorry for not remembering. All I wanted to point out is that I think this approach follows your idea too. If you think we should find a common approach then we probably should open a new topic and stop talking on the release vote :-) regards, Karl > 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 > -- Karl Pauls karlpa...@gmail.com
