aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Hughes <>
Subject Re: Semantic Versioning tool
Date Thu, 29 Sep 2011 10:58:11 GMT
Hi David, comments inline.

On 29 September 2011 11:43, David Bosschaert <> wrote:
> 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?

> However, in some cases a user of a technology also needs to implement
> an interface in order to work with that technology. Just an example
> could be the BlueprintListener. You can implement that interface to
> interact with the Blueprint components but are not considered an
> implementor of the technology. In this case the an import of [1.0.0,
> 2.0.0) should work, given that you are logically speaking a consumer
> of the technology.
> Cheers,
> David

View raw message