Managing bundles - OSGi in Action - page 298

org.osgi.framework;version="1.4"
org.osgi.service.packageadmin;version="1.2"
org.osgi.service.url;version= " 1.0 "
org.osgi.service.startlevel;version="1.1"
org.osgi.service.permissionadmin;version="1.2"
org.osgi.service.condpermadmin;version="1.0"

org.osgi.core

Interfaces and classes

OSGi Service
Platform Release 4

Figure 9.3 The platform implementation contains many subpackages
that must evolve in step with the specification, but what's the version of
the implementation?

collection of packages in this bundle has a version number based on the OSG i specifi-
cation. Figure 9.3 graphically depicts this situation.
Now, the question is, what version should you assign to the org.osgi.core bundle?
There's no single answer. You could increase the major number on every major release
of the OSG i specification, but this would indicate a binary-incompatible change in at
least one of the provided packages, which clearly isn't the case (as indicated by the indi-
vidual package versions). Another approach is to keep the version number at 1, indi-
cating that no binary-incompatible change has happened. You would then need to use
the minor number to match the release number of the specification. Because the OSG i
specification has also had minor number releases (such as 4.1), you would then need
to use the micro number for the minor number of the specification.
Unfortunately, this wouldn't be exactly what you want either, because there have
been updates in the minor numbers of the contained packages. To make matters worse,
if you ever needed to update the bundle for a different reason (like a packaging mis-
take), then you'd need to use the qualifier to express that the bundle had changed. In
the specific case of the core OSG i specification, the OSG i Alliance makes API JAR files
available based on the version of the specification (4.1.0, 4.2.0, and so on).
Although there's no single policy you can prescribe for versioning bundles, at a
minimum you should try to reflect incompatible changes at the package level in your
bundle version number. The management task to take away from this section is that
versioning is important and shouldn't be left as an afterthought. If done correctly, the
OSG i concept of versioning is extremely powerful and removes a lot of the pain from
assembling applications. To get it right, you need to define a versioning policy and
enforce it on all your bundles and exported packages.