On Thu, Jan 22, 2009 at 9:06 AM, Nektarios K. Papadopoulos <[email protected]> wrote: > > > On 2009-01-21 23:07, BJ Hargrave wrote: >> >> I don't think any change to bnd is needed. >> >> For a package which contains interfaces meant to be implemented by the >> importer, then it is a breaking change to add new methods to the interfaces. >> This is a 1.0 to 2.0 version change. Not a 1.0 to 1.1 change >> >> This is why it is probably a best practice for a package to either contain >> interfaces to be used by an importer or to be implemented by an importer. A >> package should never contain both types of interfaces since it makes >> versioning the package more awkward. > > Sorry if I misunderstand your statement, but I think that _all_ interfaces > are of both types. Each and every interface is supposed to be implemented by > an importer and used by another importer.
I believe the question on how to version interfaces is again a question of convention and... well the perspective from which you're looking at it. >From BJs point of view, it is quiet rational. As soon as any "no matter what kind" of API break appears, the major version has to be increased. This is a safe approach from the point of a bundle provider. Peters and my suggestion aims more at the re-usability of bundles but puts more burden on the "user/consumer". The advantage in my point of view is that clients of the interface (only working with the interface and not implementing it) are more flexible and can stay compatible for a longer time without the need to change the bundle. Using major versions for interface enhancements removes the possibility of anticipating new compatible versions, because the versioning scheme then isn't expressive enough. In my opinion, package versions should be determined by tools and developers should only have verify it (forcing a minimal version change based on the actual changes according to the API - maximal change is up to the developer). With such an approach the extra burden of distinguishing the usage of interfaces is gone and we can be way more confident with 3rd party bundles that they are using the same versioning heuristics as I do or at least won't break anything without notifying me. Cheers, Mirko _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
