On 29 September 2011 11:58, Jeremy Hughes <[email protected]> wrote: > On 29 September 2011 11:43, David Bosschaert <[email protected]> >> > On 29 September 2011 11:32, Emily Jiang <[email protected]> wrote: >>> On Thu, Sep 29, 2011 at 11:24 AM, David Bosschaert < >>> [email protected]> wrote: >>> >>>> Hi Emily, >>>> >>>> I'm not sure that's sufficient... Just a small example. >>>> >>>> Let say your bundle provides an interface FooCallback that users of >>>> your project need to implement to receive callbacks. If you add a >>>> method x() to that interface, all of your consumers will stop to >>>> compile. This should be a major version upgrade. >>>> >>>> In this case, according to semantic versioning white page, the implementor >>> limits its version range to a minor version changes e.g. [1.0.0, 1.10). It >>> should not tolerate any minor version changes. Any minor version changes >>> will not make into this client. >> >> I'm happy to be proven wrong but I think the definition of an >> implementor is not as simple as you describe above. >> >> I think that, in the context of semantic versioning, an implementor is >> considered to be someone who provides an implementation of a >> technology. Like for instance Apache Aries is an implementor of the >> Blueprint technology. > > I think it's on a package level, not a technology level. > > To quote the white paper (executive summary): > > "A package can contain an API. There are two types of clients for > these API packages: API consumers and API > implementation providers. A change in the second (minor) part of the > version signals that the change is > backward compatible with consumers of the API package but not with the > providers of that API. That is, > when the API package goes from version 1.5 to 1.6 it is no longer > compatible with a provider of that API but > consumers of that API are backward compatible with that API package." > > An implementer of BlueprintListener is an API implementation provider. > A single class can be an API implementation provider of > BlueprintListener while being an API consumer of other blueprint > packages. I don't believe the whitepaper describes the subtlety you > allude to. Have I missed something?
And again, I may have missed something here too :) The situation that I'm describing here is that *within* a single package (e.g. the org.osgi.service.blueprint.container package to stay with our example) one could be a consumer while still implementing an API provided by that package. That's why when in our example when org.osgi.service.blueprint.container.BlueprintContainer gets a new method only the minor version of the package needs to be increased (as consumers don't implement this interface) but when org.osgi.service.blueprint.container.BlueprintListener gets a new method the major version of the package needs to be increased as consumers do implement this interface, but given they're a consumer should be allowed to specify a version range like [1.0.0, 2.0.0). Cheers, David
