aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bosschaert <>
Subject Re: Semantic Versioning tool
Date Thu, 29 Sep 2011 11:25:38 GMT
On 29 September 2011 11:58, Jeremy Hughes <> wrote:
> On 29 September 2011 11:43, David Bosschaert <> >>
On 29 September 2011 11:32, Emily Jiang <> wrote:
>>> On Thu, Sep 29, 2011 at 11:24 AM, David Bosschaert <
>>>> 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).



View raw message