commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <bdelacre...@apache.org>
Subject Re: OSGi Version at Package Level
Date Tue, 20 Jun 2017 09:12:33 GMT
Hi Stefan,

On Thu, Jun 15, 2017 at 6:53 PM, Stefan Bodewig <bodewig@apache.org> wrote:
> ...We use the default configuration of the bundle plugin, only marking some
> imports as optional. So we are exporting all our packages...

Ok. In the OSGi world it's only APIs and utility classes that should
be exported, implementations should be hidden.

But this requires separating these things (API, public utilities,
implementation) in their own packages - if you don't do that, using
OSGi semantic versioning might not help much and the whole thing might
be moot.

And reorganizing your packages might cause too much pain compared to
the benefits, although it's good in the long term. So maybe something
for a major release.

> ...If the API of a package changes with a new release we are on the safe
> side with the current approach...

Yes. You might cause unnecessary incompatibilities with client OSGi
bundles that specify a restricted import versions range, that's
inconvenient but not dramatic.

>
> ...What is the expectation if only the implementation of a package changes?...

That should be invisible from the OSGi side of things. You will
mention in your release notes that users need to upgrade to the new
*bundle version* to get the new implementation, but the versions of
the OSGi exported packages wouldn't change.

Again this is moot if everything's exported or if packages mix things up.

> ...What is the expectation for the format specific packages if the version
> of the utils package they internally depend on changes? Do the format
> specific packages need a version update as well? Does the bundle plugin
> detect this?...

The format specific packages should be only implementation, correct?
With only their APIs being exported.

>
>... What bad happens if the published version of a package changes even if
> there is no change at all - this is what happens for some packages if we
> keep on doing what we have done all the time....

As above - this will require some OSGi users to upgrade or recompile
other bundles that depends on yours, although technically that
wouldn't be needed.

> ...What I really wanted to say is if the bugfix means the exported package
> version now is "1.17.1" and the bundle version is "1.19" won't we
> confuse the hell out of our users if we tell them they need version
> 1.17.1 of the package that's contained inside of Compress 1.19 - as
> opposed to telling them "upgrade to Compress 1.19"?...

If the exported package versions haven't changed (because the bugfix
code is implementation only so not exported) , in OSGi you can use
either the old or the new version of the bundle, without any other
changes to your system as OSGi won't see the change. Users will have
to be informed to upgrade to 1.19 to get the bugfix, and based on no
exported package versions having changed they will know they don't
need any other changes in their system.

> ...I'm also afraid we'll have to grep through git logs to figure out which
> version of Compress a bug is reported against if the reporter talks
> about the version of an exported package rather than the version of the
> bundle....

They shouldn't, tracking should always happen against the version of
the artifact that you release. Exported package versions then
naturally derive from whatever changes are made, and provide API-level
compatibility guarantees that are very useful in large systems.

>... Maybe I'm making a bigger problem of this than it really is...

I think the key is cleanly separating the code so that Java packages
do not mix APIs, public utilities and bundle-private code.

If that's done, the rest follows naturally.

If that's not done, having independent version numbers for each
package might cause more pain that benefits.

HTH, and nice "talking" to you Stefan after all this time!
-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message