aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: Release / verisoning requirements (was Re: svn commit: r1066827 - /aries/branches/experimental-release-by-module/)
Date Mon, 07 Feb 2011 19:16:19 GMT
On Mon, Feb 7, 2011 at 18:21, Graham Charters <> wrote:
> Hi, a couple of questions/comments...
> On 7 February 2011 15:51, Guillaume Nodet <> wrote:
>> Those are the requirements I would consider important for a release.
>> If not all those requirements are compatible, we need to agree on
>> removing some requirements or weaken them I suppose.  I just want
>> everyone to understand what the development and release processes will
>> look like when we have defined our solution.  If we don't agree with
>> the outcome, we'll have to go back to this requirement list and modify
>> those or find a different technical solution.
>> I think I'd like everyone to think about is read the semantic
>> versioning whitepaper and give it some thoughts.  What problem does it
>> try to solve?
>> It in fact remembers me of some discussion I had a few months / years
>> ago about a bundle importing / exporting its own packages.  Someone
>> quote Peter Kriens that such a behavior was indeed a good practice.
>> When I wanted to have bundles only exporting the packages, there were
>> some push back (the discussion was actually on
>> about a patch I submitted).  Those guys were not really OSGi experts,
>> so the only thing they could do was to blindly follow so called best
>> practices, hereby forgetting about the context of those best
>> practices.  Importing/exporting a package is about increasing
>> substituability of packages in the OSGi framework, so it only makes
>> sense for a *real* API.  A library such as commons-io or lots of
>> projects which are not developed *for* OSGi (i.e. they are mostly
>> developed as libraries) can't use this policy as this would plainly
>> break the whole system if you try to deploy multiple versions.
>> Now, back to semantic versioning.  *I* think the overall goal of
>> semantic versioning is to make sure the users of our packages know
>> what to expect when they import a package with a given range.   I.e.
>> if they just use a package, something like [1.0,2.0) should work.   If
>> they implement some of our interfaces, they should use a stricter
>> package such as [1.1, 1.2).   The rules are just here to provide
>> guidelines that should be followed to ensure that.
>> That said, the part I tend to slightly disagree with is that we should
>> *only* bump the micro version if there has been a change, or that we
>> should only bump the minor version if there has been an imcompatible
>> change from an implementer point of view (and here, what does this
>> mean for packages that are not pure API? I guess one conclusion is
>> that the whitepaper does not really talk about those, just about pure
>> api packages), or that we would not be allowed to change the major
>> version if there is no incompatible change.
> What would the motivation be for bumping versions that imply greater
> incompatibility, which is what I think you're suggesting you'd like to
> do?  If we do this, then this has a knock-on effect of imports.  How
> does a consumer know what range to import?  If they follow the OSGi
> Alliance best practice, then they'll have to change their imports more
> frequently than necessary and there'll be fewer opportunities to put
> together coherent sets of bundles and less opportunity to fix systems
> without having a knock-on effect on other bundles.  We make the
> dependencies more brittle.

That's only the case when you implement one of our API which is much
less frequent.  But I'm much more worried about exported packages that
contain code, not pure API packages, as I agree those could be
versioned with semantic versioning.  For example blueprint-core
exports all the packages, not only api packages.  In such a case, the
semantic implied for those packages is much less obvious than for a
clean api package, and I'd really like to leave room for bug fix
release in those cases.  But even for api, I'm still on the fence, see

>> And the reason why I disagree with that is that it does not help
>> solving the compatiblity problem, the goal here is to reduce
>> class-space fragmentation.   Class-space fragmentation however has
>> other solutions I think, and applications / subsystems are clearly a
>> way to solve that problem.
> Semantic versioning helps maximmise sharing and flexibility of
> assembly.  Sticking to this policy maximises the opportunities to
> create a consistent solution from a set of bundles.  Applications and
> subsystems don't solve all the same problems. Granted, you can use
> them to partition up the classspace, but what if you actually want a
> consistent class-space across the bundles because they share types.
> Partitioning up the class-space won't solve that, only having flexible
> imports that maximise resolution opportunities will solve that.

I disagree that it actually helps creating a consistent solution because:
1/ you may end up needing the same jar in multiple versions (that's
not really consistency to me) though it does not cause much harm, I
2/ the test matrix (if you ever want to do tests) has to grow
exponentially as you have less control over the wirings

For example blueprint would have to be tested with all proxy service
implementations in order to guarantee the behavior, whereas
restricting the range to a minor by default and bumping each with each
minor release, improve the testability and the readiness of the
Well, at least, I'd rather give to customers something I know work
rather than relying on untested interactions.

Just a recent example: the commit i've done in blueprint-core seems to
have raised a problem in the blog sample which has been fixed in the
proxy service.  There's no way to capture such information and if we
even have no room for doing maintenance releases, i don't how what
kind of benefit it will bring to our users.

I think the theory of semantic versioning is great, but in practice,
I'm still not sure the benefits outweight the problems, at least when
applied strictly to non pure API packages.   For pure API packages, I
would tend to think they should actually be released completely
separately to make sure they have their own release cycle and
life-cycle and minimize the changes.

>> I'd rather have a way to have bug fix release and raise the level of
>> fragmentation ....  But if we decide to go to a strict application of
>> the semantic versioning, I'd like everyone to understand that we won't
>> be able to do bug fix releases.
>> Just my 2 cents.
>> On Mon, Feb 7, 2011 at 16:30, zoe slattery <> wrote:
>>> Hi
>>>> Well, given I still haven't understood how we're going to release
>>>> things (per bundle or per component, as it seems a single whole
>>>> release hasn't really received much support), I think our current
>>>> layout conflict with #6 and we still haven't found a clear way to
>>>> align #1 with #7 afaik.
>>> Yep - but if we accept your requirements we have to find a way to align #1
>>> with #7, don't we?
>>> Finding a way to meet #6 is hard. I will go on experimenting and come up
>>> with a concrete proposal for discussion later this week I hope.
>>> I will collect up your list and put it on the Website somewhere so that it
>>> doesn't get lost.
>>> By the way - does Sling meet all of these requirements? Because one option
>>> (if someone is doing it right already) is simply to copy their process.
>>> Zoe
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog:
>> ------------------------
>> Open Source SOA

Guillaume Nodet
Open Source SOA

View raw message