commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: OSGi Version at Package Level
Date Mon, 12 Jun 2017 14:39:36 GMT
On 2017-06-07, Bertrand Delacretaz wrote:

> On Wed, Jun 7, 2017 at 9:10 AM, Emmanuel Bourg <> wrote:
>> ...Do I understand well that we would have to micro manage versions at the
>> package level different from the version at the component level, and
>> sometimes significantly different versions (like foo 1.2.3 and
>> 2.3.4)?...

> That's how it's done in OSGi-based systems.

>> ... That sounds like a nightmare...

> With the right tools as mentioned in my previous message it's quite easy.

>> ...What existing problem would that solve exactly?...

> Implementing semantic versioning at the java package level as opposed
> to bundle level.

> In heavily componentized systems that's a big help, assuming the Java
> packages make sense - to paraphrase Grady Booch, one package should do
> one thing and one thing well.

> On the other hand, if you don't care about package-level versioning
> and consider your bundle as one big thing on which other things
> depend, that doesn't help much.

Compress, which is targeted by Simon's pull request, is probably one of
the few components where package level versioning might make sense. For
most of our releases the packages are independent of each other and many
of our implementation packages don't change at all with new releases.

I'm not a citizen of OSGi land and find it hard to fully understand
whether the suggested changes make things better in any way.

Right now we bump all package level versions together with the
artifact. We intend to use semantic versioning, if we've failed to do so
in the past, then this is the problem more than whether the version
applies to the package or the library as a whole.

So I've got a bunch of practical questions:

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?

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

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)?

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?


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

View raw message