commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: OSGi Version at Package Level
Date Thu, 15 Jun 2017 16:53:06 GMT
On 2017-06-12, Bertrand Delacretaz wrote:

> 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.

Thanks, Bertrand. You don't really need to know specifics about
Compress. It contains some packages that provide the generic API for
compression and archiving and they don't change that often. Then there
is a utils package that changes more frequently. And we've got a bunch
of format specific packages, many of which don't change at all between
versions, some of them only change the implementation (fixing bugs) and
some may add new methods or classes to add format specific features.

We use the default configuration of the bundle plugin, only marking some
imports as optional. So we are exporting all our packages.

To be honest I still feel I must be missing something.

So far all packages have the same version as the library itself,
i.e. they change the minor version with each release, even if there is
no change at all.

I do understand why signaling a minor change when there really is a
major change is a problem. But this is unrelated to the OSGi issue, so
I'd like to leave this out.

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

What is the expectation if only the implementation of a package changes?
If we need to update the version of the package as well, them I'm afraid
no tools is going to catch this.

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?

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.

> On Mon, Jun 12, 2017 at 4:39 PM, Stefan Bodewig <bodewig@apache.org> wrote:

>> ...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.

This is what I've rephrased above. "ar" depends on "util" internally,
but that's (currently?) not visible looking at the list of exported
packages.

>> ...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.

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

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.

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

Stefan

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


Mime
View raw message