Version changing in OSGi packages

Question

I am thinking of the best way to manage versioning in our project. For now, every package in our bundles is exported (this will be improved later so don't get hung up on this faux pas). We are using the maven-bundle-plugin, which either takes a package version from a packageinfo file or if there are no files, from the bundle-version (i.e. the pom version).

So my question is, it seems that having a packageinfo for every package is a lot (again, i know reducing exported packages fixes this) so I'm wondering why is it better to have a version per package as opposed to a global version (bundle-version)?

So say bundle A is released

 A (1.0.0)
 |...foo (1.0.0)
 |...bar (1.0.0)

now if package bar changes, the ideal way to release bundle A would be

 A (1.0.1)
 |...foo (1.0.0)
 |...bar(1.0.1)

Would it be so bad (if so, why?) to have a single version so that foo is released as 1.0.1 even though its content didn't change? because apart from having a packageinfo file in every exported package, developers also need to remember to bump the version (and they will forget), whereas the version of the bundle is bumped automatically by the maven-release-plugin. Please note I'm not talking about using require-bundle. i still want to use import-package to have the granularity that it brings and have the option, if needed, to control the package version by means of a packageinfo, but i'm trying to simplify developers' workflow and memorization and one idea was to leave packageinfo only for special cases instead of the recommended "everywhere"

The way a see it, being very pragmatic, i have to choose between the dangers of releasing two different packages with the same version (developer forgot to bump number after change), which seems very bad to me VS releasing two equal packages with different version, which i don't know what dangers it entails, hence my question

Answer 1

The way you manage versions should probably depend on the kind of software you write. In any case whatever you export as a package is either an API (be it internal or public) or a library you want to share. You should only expose the minimum packages to achieve good decoupling.

Now as you mentioned there are two popular schemes of versioning:

1. Versioning the whole bundle. This means every package export has the version of the bundle
2. Versioning each package separately

Variant 1 is suitable if mainly your own application depends on the the shared packages. It is also popular for libraries as it is easy to add to existing libraries. The main advantage is that it is easy to achieve. Simply let the maven bundle plugin use its defaults. it works best if the bundles using you shared packages are released together with the bundle exporting the packages.

Variant 2 is good for APIs that are used by many loosely coupled other applications. Careful version management by package ensures that a change in the API has minimum impact on existing users. The price is that you need a lot more consideration and effort to manage the versions well. So a good example for this are the OSGi specs. They achieved a great level of compatibility while introducing new features over time.

I can share a case where versioning by bundle was not optimal. The first preview of the servlet API 3.0 only exported the 3.0 package version. So if this would have been the official release then every bundle that used the old API 2.5 would have had to switch as default import ranges always exclude the next major version. In the end the new and the old version was exported for all compatible packages. So that minimized the impact on users.

Btw. if you use the maven bundle plugin then the user of a bundle does not have to do much even in case of versioning by package. Bnd automatically looks into the version of each package and bases the import range on this information instead of the bundle version.

So basically think about the impact on users. Especially when you do a new major version. Test a user bundle compiled against the old version of your bundle.