Hi Stefan, On Thu, Jun 15, 2017 at 6:53 PM, Stefan Bodewig <bode...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
