Bundle versions & Interfaces versions

[ego]

I've a question / thought about the link between a version of a bundle and the version of its interfaces.
Maybe I'm wrong but I think that if we've to manage the versions of the dependency between two bundles (A needs B for example) is because we've to manage the versions of the provided interfaces (interfaces of B).
So don't you think that something should be explained about "how to manage the versions of the interfaces of a bundle" (and how they are imported into other bundles).
If bundle A needs to switch from version 1.0 of bundle B to version 1.1 of bundle B it is probably because at least one interface has changed. And if bundle C depends on bundle B version 1.0 you cannot share the interfaces of B between A and C. So A and C have their own versions of the interfaces of B.

Not sure I'm clear ...

Any point of view, anyway ?

[Glyn Normington]

This whole area was discussed quite a bit in the OSGi R4 standards work. We had to decide whether to give special meaning to specification-version or whether to treat it as a synonym for version.

In the end we decided to treat it as a synonym to avoid the confusion of having an interface whose specification-version had not changed but whose implementation version had changed and trying to define client compatibility policies based on two version numbers.

The way to approach this area is to bear in mind that each interface belongs to a package and every exported package has a version number. This version number should be considered to be the version of the interface. This is completely separate from the bundle versions of the bundles exporting and implementing the interface.

(There is a subtlety which can help in some edge cases, but which you should ignore as a general policy. On rare occasions where clients of an interface have adopted a strict version range policy (e.g. using ranges like [1.1,1.1]) and a new version of the interface is available which is strictly backward compatible, then it is possible to export the same package multiple times with distinct version numbers from a given bundle. This can enable "strict" clients to wire to the new version (via the older version export).)

With that in mind, please see if that helps the scenario you have in mind and post back here if not.

[ego]

Yes probably that the implementation-version doesn't matter.
But you can says that a version N+1 is backward compatible with version N. If you define a version N+1 is because this version is different from version N.
So, all bundles that depends on this interface needs to be re-compiled. Imagine a information system with 100 "applications" that depends on one another (name it B). If theses 100 applications are not "sitcked" with version N of the interface it means that you've to re-compile all of them and probably test them again and re-deploy them. It's not possible. So I cannot see how you cannot depends on a strict version of an interface. You can "internally" (intern of an "application") but you cannot "externally".

[Glyn Normington]

These are mainly issues of how to evolve a Java interface in a backward compatible manner. Certainly this is impossible, strictly speaking because you can always use reflection to detect changes in an interface. But "normal" non-reflective users of an interface do not have to be recompiled or impacted in any way if certain careful changes are made, such as adding a method.

That said, there's nothing that dm Server can do to solve this problem in Java.

[ego]

I understand...
Maybe that one solution can be to manage an inheritance tree of interfaces. I mean Interface N+1 inherits from Interface N and yes it's not necessary to recompile all dependant bundles. Of course it works if you add a method, it's more complicated if you modify an operation signature but solutions exist.

Thanks for your feedback