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