Ok, I am done for now with the page [1]. Over the course of an hour or
two, it should also be synchronized to the site.

Note, that I still kept the unsynchronized version numbers because in
practice the best we can do is apply the same semantics to package and
bundle versions when it comes to increasing. But we will not be able to
keep them in sync in any way -- unless we are ready to have "holes"
(which would also not be a bad thing per se.

Please comment. Thanks.

Regards
Felix

Felix Meschberger schrieb:
> 
> 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
> 

Reply via email to