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 <bode...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
