Hi David, To clarify, this tool scans export package and bundle version not import package, as we know the import package needs human intervention. This might explain the confusions.
Thanks Emily On Thu, Sep 29, 2011 at 1:20 PM, Emily Jiang <[email protected]>wrote: > I think this is a discussion regarding how to label a consumer or > implementor For your example, the client is both a implementor and consumer. > My take is that when you need to implement any interface you will be a > implementor. Therefore, the client should limits to minor version changes. > However, as far as package semenatic versioning is concerned, it should > purly depend on the package owner not by the usage. > Regards > Emily > > > On Thu, Sep 29, 2011 at 12:25 PM, David Bosschaert < > [email protected]> wrote: > >> 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 >> > > > > -- > Thanks > Emily > ================= > Emily Jiang > [email protected] > > -- Thanks Emily ================= Emily Jiang [email protected]
