On 17 Nov 2009, at 06:48, Alexander Klimetschek wrote:
* Extend package2 API, thus:
version 1.2.0
exports package1,version 1.1
exports package2,version 1.2
contains implementation code...
And now, if package1's API changes (version 1.2), what's the bundle
version number?
no, version 1.3
I'd suggest 1.3.0, i.e. bump up the middle number whenever a package
version changes.
Exactly, because package1 becomes 1.3
(middle number == minor version number)
That sounds good to me. That way one could ignore the package versions
if he likes to (I know you shouldn't, but it's more natural for people
new to osgi).
+1 for "testing it" with the sling api bundle.
+1 for testing, however
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 ?
Ian
