Hi, On 09.02.2010 21:13, Karl Pauls wrote: > 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 :-)
I don't get you wrong. And maybe we should differentiate between the framework (which is primarily just a JAR file and is probably different, or "the exception to the rule") and regular bundles. I am more concerned with bundles and in thus the bundlerepository bundle here. Regards Felix > > 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 >> > > >
