commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <>
Subject Re: OSGi Version at Package Level
Date Mon, 12 Jun 2017 15:07:15 GMT
Hi Stefan,

I'll do my best to answer from my heavy OSGi user's point of view -
but as mentioned I know little about the specifics of Compress.

On Mon, Jun 12, 2017 at 4:39 PM, Stefan Bodewig <> wrote:
> ...Say we started versioning packages with 1.15 and all untouched APIs stay
> at 1.14. We update package versions whenever there is an API change. We
> go ahead and fix a problem with an implementation detail in - say - "ar"
> in 1.19 but there is no API change. Would we modify the package version?...

No, in the OSGi world the Java package versions are completely
independent of the version of the bundle that provides them.

You can actually have several bundles providing the same package, and
the OSGi framework will do the right thing and wire the most recent
version only, unless dependencies specify something different. I
digress and that's kind of an edge case but that helps explain the
concept I think: each exported package (others ones are invisible in
an OSGi system outside of their own bundle) has its own version cycle,
independent from anything else.

So in practical terms you define the version number of the bundle as
usual, driven by your perception of how much it changes, and it's the
package version numbers that are actually important in an OSGi system.

> ...What if we change the implementation in "util", not in "ar", what is
> going to happen to the version in "ar"? What will the bundle plugin tell
> us?..

if util is exported and changes require a version number increase then
you do that.

And if ar has not changed its version number stays the same.

And if a package is not exported it doesn't have an OSGi version
number, its changes only affect the implementation but not the wiring
with its clients.

> ...Would this mean we'd need to start using bugfix version numbers for
> packages where the implementaion changes but the API doesn't? I.e. "ar"
> in Compress 1.19 would have version 1.14 (no API changes) or 1.14.5
> (five implementation changes since 1.14)?...

Yes that's totally possible as the package has its own version numbering cycle.

> ...How would we tell our users to upgrade to version 1.19 in order to use a
> bug fix that has been applied if this is the version of the library as a
> whole and not the version of a package?...

If an non-exported implementation package includes changes then you
can tell your users to upgrade that bundle to include those fixes but
at the OSGi level those changes are invisible as the OSGi framework
only sees exported packages.

That's an implementation upgrade then, but if exported packages have
not changed you can guarantee that the system will startup without
requiring any other upgrades, that's the beauty of OSGi.

And if the version of an exported package changes, it will cascade
into the whole system and force you to upgrade bundles that depend on
it (based on their importing version range), which guarantees that if
your system starts it has all the right versions.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message