Bertrand Delacretaz schrieb: > On Tue, Nov 17, 2009 at 3:28 PM, Ian Boston <i...@tfd.co.uk> wrote: >> ...I think package1 should be allowed to be v 1.2 and then the bundle version >> would be 1.2.1 >> >> If the package versions jump the range of versions will diverge within a >> single bundle and the rate of version number change of the bundle itself >> will accelerate (sort of positive feedback). Over time I think this will >> lead to confusion since there could be many missing versions of each package >> and a highly complex bundle version history. >> >> Incrementing of package version numbers without holes in the sequence for >> each package, coupled with sub-minor releases of the bundle will lead to a >> converging version history that IMHO will be easier to understand and track >> (its hard enough for a OSGi newbee as it is) >> >> Only when one of the packages ups its version to 1.3 does the bundle move to >> v1.3.0 >> >> Did that make sense ?... > > Mostly yes, but I think we need a wiki page with several examples like
Is ok for me, too. I am not really sure how to increase version numbers of bundles mixing exported API and implementation, like for example the Sling Engine bundle ... > the ones Felix showed and like yours above. I have started a page on this (part of the offical documentation) at [1] > > Did I mention this was going to be confusing? ;-) Well, only in the first place, you get used to it ;-) Regards Felix [1] http://cwiki.apache.org/SLINGxSITE/version-policy.html
