OSGI exported package version inconsistent with bundle version

[GoogleCodeExporter]

The exported packages in version 2.0.0 of guice are declared as 1.2.0.  I don't 
know if it's normal or if the increment was forgotten, but right now it seems 
impossible to add a version check for version 2.0.0 and higher.

Original issue reported on code.google.com by ebelange...@gmail.com on 19 Aug 2010 at 3:34

[GoogleCodeExporter]

Firstly this is *not* an error or a mistake, it is a deliberate versioning 
policy that many other third-party OSGi and specification libraries use.

OSGi lets you version packages separately to the bundle version. This is very 
useful because you can then use package versions to declare compatibility 
between releases while still using the bundle version to mark major releases.

For example, Guice 1 and Guice 2 were major milestones, but the exported API is 
still compatible: you can take an application written against Guice 1 and use 
it with Guice 2. This compatibility is expressed in the *package* versions, 
according to the scheme suggested by the OSGi Alliance:

  major.minor.micro

  major = breaking change
  minor = new feature, but still compatible
  micro = small bug fix, still compatible

And this should continue with the next release - the expected package export 
version for Guice 3 will be 1.3, because the primary API is still compatible 
with Guice 1.

This scheme makes it very easy for you to add version checks on your imports.

For example say you tested your application with Guice 1, but wanted to allow 
the client to use any later release that's still compatible with Guice 1. To do 
this you can simply use an import version range of "[1, 2)".

And if you tested with Guice 2, but wanted to allow later compatible releases 
you can use a range of "[1.2, 2)". ie. match any package version from 1.2 
(inclusive) up to the next breaking/incompatible change.

You couldn't do this if the package version was tied to the bundle version - 
we'd have to bump up the package version on every release even if the exported 
API didn't change, and you'd have no guarantee which API version is compatible 
with another. (Your client bundle would effectively end up tied to a single 
release of Guice.)

Original comment by mccu...@gmail.com on 19 Aug 2010 at 3:56

• Changed state: Invalid

[GoogleCodeExporter]

Very interesting answer and I thank you for taking the time to explain it in 
detail.  From what I am understanding, using this scheme, you can have the 
bundle version mark milestones and releases while the package version is the 
one you should check for compatibility.  Using this though, you can't really 
use the required-bundle for range check compatibility, but I clearly see the 
advantages.

Thank you again.

Original comment by ebelange...@gmail.com on 20 Aug 2010 at 12:55

[GoogleCodeExporter]

Correct, but ideally you shouldn't be using Require-Bundle at all because it 
limits you to matching against a very specific bundle (by name) whereas 
Import-Package lets you match against any bundle that exports a compatible 
package (by capability).

Require-Bundle was actually introduced relatively recently (in the history of 
OSGi) for specific use-cases involving legacy code in Eclipse.

Original comment by mccu...@gmail.com on 20 Aug 2010 at 1:01