On Tue, Nov 17, 2009 at 13:28, Felix Meschberger <fmesc...@gmail.com> wrote: > Hi, > > Bertrand Delacretaz schrieb: >> On Tue, Nov 17, 2009 at 1:17 PM, Felix Meschberger <fmesc...@gmail.com> >> wrote: >>> ...How about this: >>> >>> * The bundle version number is always >= the highest version >>> number of all exported packages. >>> * If only implementation fixes apply to a bundle, the micro >>> number is increased >>> * If the version number is to be incresed it is set to the next >>> minor version number of the bundle.... >>> >>> ...* Extend package1 API, thus: >>> version 1.1.0 >>> exports package1,version 1.1 >>> exports package2,version 1.0 >>> contains implementation code >>> >>> * 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. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
