Set Export-Package versions on a per-package basis

[GoogleCodeExporter]

There is an issue about Guava and the next Eclipse Simultaneous release (see 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=427862).

Some participants are using a version of guava while other use another one. 
This cause some ClassCastException between plugins. This would be less frequent 
if the packages were exported with a semantic version instead of the global 
release number. This way, Guava's user may be confident while importing package 
with a range dedicated to their usage.

I will try to propose a patch to the POM file with comments made on 
https://www.osgi.org/bugzilla/show_bug.cgi?id=161. But first, I would like to 
know if the guava team member agree with such a change (knowing that it does 
not change anything for anyone not using OSGi, but helps a lot people using 
it...)

Best.

Original issue reported on code.google.com by mikael.b...@gmail.com on 25 Feb 2014 at 2:40

[GoogleCodeExporter]

We actually do use semantic versioning with Guava. Every Guava release may 
contain incompatible API changes (according to the policy for @Beta and 
non-@Beta APIs described here: 
https://code.google.com/p/guava-libraries/wiki/PhilosophyExplained#Beta_APIs) 
and as such, every major release requires a new major version in accordance 
with semantic versioning.

Original comment by cgdecker@google.com on 25 Feb 2014 at 5:09

• Added labels: Package-General, Type-Other

[GoogleCodeExporter]

Semantic versioning is not about what a release *may* contain compared to the 
previous release but how much it *has* changed. Moreover, I am not suggesting 
to change the release numbering of Guava in any way. Most of the time the major 
bump is required because at least one of its package has been broken. But some 
packages are very stable, and people wants to be able to be linked to a newer 
version of guava if they only use packages that contains no API breakage for 
them.

I am proposing to change the versioning of exported packages (i.e. in the 
MANIFEST.MF, the version of the packages listed in the export-package 
directive). It is something that is really useful in an OSGi environment. The 
idea is: if a package A did not change its API from one version to another, 
only the micro part of its version is incremented; if it changed its API for 
providers (i.e. implementers), its minor part is incremented; and if its API 
changed for consumer (i.e. users of the API) then the major part is upgraded. 
See http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf if you are 
interested in the reasoning.

This numbering can be made automatic and I'm proposing to implement this 
automation in the POM. Are you OK with that?

Original comment by mikael.b...@gmail.com on 25 Feb 2014 at 5:27

[GoogleCodeExporter]

Would it be accurate to title this bug "Set Export-Package versions on a 
per-package basis?"

Original comment by cpov...@google.com on 25 Feb 2014 at 5:35

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Yes, it would be absolutely accurate.

Original comment by mikael.b...@gmail.com on 25 Feb 2014 at 5:37

[GoogleCodeExporter]

Original comment by cpov...@google.com on 25 Feb 2014 at 5:38

• Changed title: Set Export-Package versions on a per-package basis

[GoogleCodeExporter]

FIY, I'm waiting for an answer on 
https://issues.apache.org/jira/browse/ARIES-1159 before going further.

Original comment by mikael.b...@gmail.com on 6 Mar 2014 at 6:40

[GoogleCodeExporter]

+1

We think of bundling guava with our web application framework, where backwards 
compatibility for customer code is very important, but because all package 
exports always change in the major version, we couldn't update guava with a new 
release of our product, as customer code/bundles would always break. If package 
export versions for the packages that don't get an incompatible API change 
(most of them afaics) would not get updated, this problem would be greatly 
reduced to those cases where it actually is necessary to adapt client code.

Original comment by alexande...@googlemail.com on 15 Sep 2014 at 5:17

[GoogleCodeExporter]

I see you're trying to use the aries versioning plugin to help with semantic 
versioning. Since that does not seem to be really maintained, perhaps you can 
try using the maven-bundle-plugin, which since version 2.5.0 can generate 
baseline reports and even fail the build if changes are not taken into account 
through versioning.

The documentation is mostly at https://issues.apache.org/jira/browse/FELIX-4512 
, but I'm happy to answer any questions you might have about its usage.

Original comment by robert.munteanu on 16 Sep 2014 at 9:04

[GoogleCodeExporter]

Thanks Robert for pointing this out. I will give it a try very soon.

Original comment by mikael.b...@gmail.com on 18 Sep 2014 at 10:09

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:09

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:17

• Changed state: Migrated

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:07

• Added labels: Restrict-AddIssueComment-Commit