aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: Release by module - changes to trunk
Date Tue, 01 Feb 2011 16:58:40 GMT
On Tue, Feb 1, 2011 at 16:17, zoe slattery <> wrote:
> On 01/02/2011 14:54, Guillaume Nodet wrote:
>> This is very different from what we have I think, as gogo's root pom
>> isn't used at all.
>> Releasing gogo involves releasing each of the maven subproject
>> independantly afaik.
> That might be true - I'm struggling with the logic at the moment. Wondering
> why the development version of the gogo
> runtime is 0.9.0-SNAPSHOT and the latest release seems to be 0.4.0 If there
> were released independently wouldn't the next
> development version be either 0.5.0-SNAPSHOT or 0.4.1-SNAPSHOT depending on
> the nature of the change? Oh well - probably not
> something to worry about.

You should not look at the root gogo pom as it's not used at all afaik.
The scheme has changed after 0.4.0, so newer releases are available at:

>> The main difference is that all felix releases consists of a *single*
>> bundle.
> Yes - that was my conclusion too.
>>  If we go this way, that would mean that releasing blueprint
>> only would require 13 releases.  Some of those just contain tests, so
>> that does not make sense to me.
> Completely agree.
>>   From an usability point of view, I
>> would definitely not go that way.  I'd personaly rather go in the
>> opposite direction and use a single reactor / release for all
>> components.
> Well - that is where we are at the moment - so it's the least effort :-)
> I think it would be good to be able to release modules independently but a
> combination
> of having sub-modules and wanting not to break semantic versioning is making
> this difficult. Although - in effect - I suppose we
> do not follow semantic versioning already.

I think we could improve the semantic versioning at the package level
without affecting the bundle release cycle if we want.
That would mean that we'd have to have a separation between the
package versioning and the artifact versioning, which imho makes more
sense, as you could do multiple releases of the same package (for
example if a bundle contains multiple packages in different versions).

>> Another consideration is that I think we should tie the release cycle
>> with the svn layout, i.e. if we want to keep each component with a
>> separate lifecycle, we should have multiple trunks.   That's way
>> cleaner imho (and much more git friendly btw).
> Do you mean that there would be a trunk for each module?
> I'm not sure that I can see what multiple trunks would be like, does anyone
> else do this? Could you explain a bit more?

One trunk for each component.
So we'd have

Lots of projects do that.

It's just I'd like a clean mapping between a trunk/release/tags and a
release cycle, so if we have a single release cycle for all
components, use a single trunk.  If each component has its own release
cycle, use separate trunks.

>> On Tue, Feb 1, 2011 at 15:25, zoe slattery<>  wrote:
>>> Hi Felix
>>> I had a look at felix to see if I could work out how you do the
>>> independent
>>> releases. I didn't look through absolutely everything but
>>> I only found two modules that had sub-modules (gogo and http). Of those
>>> two
>>> it looks as though the pom structure in gogo might be similar
>>> to what we need in Aries. Is this a model you would recommend? Or is
>>> there
>>> something closer?
>>> Zoe
>>>> Hi,
>>>> Am Montag, den 31.01.2011, 15:22 +0100 schrieb Guillaume Nodet:
>>>>> Wouldn't that imply that each bundle has its own lifecycle ?
>>>>> I think a while ago we agreed on having one release per "component",
>>>>> i.e. blueprint (which includes api + core + cm + ...).
>>>>> I'm not sure how well this would go if we have blueprint-core
>>>>> 0.4.0-SNAPSHOT depending on blueprint-api-0.3.0.
>>>> I bet you won't release blueprint-api as version 0.4.0 if it is the same
>>>> as 0.3.0, right ?
>>>> Regards
>>>> Felix
>>>>>>  From a users point of view, it certainly does not help because
>>>>>> the
>>>>> maven transitive dependencies are kinda screwed.
>>>>> On Mon, Jan 31, 2011 at 15:11, Felix Meschberger<>
>>>>>  wrote:
>>>>>> Hi,
>>>>>> Am Montag, den 31.01.2011, 13:59 +0000 schrieb Jeremy Hughes:
>>>>>>>>> (c) Where an Aries module depends on other Aries modules,
it will
>>>>>>>>> depend
>>>>>>>>> on the released versions of the other modules _until_
it requires a
>>>>>>>>> change in the module that it depends on, at which stage
it will
>>>>>>>>> switch
>>>>>>>>> to a dependency on the development version.
>>>>>>>>> So for example, Blueprint 0.4-SNAPSHOT will depend on
quiesce 0.3,
>>>>>>>>> proxy
>>>>>>>>> 0.3, testsupport 0.3 and  parent 0.3. If blueprint 0.4-SNAPSHOT
>>>>>>>>> needs
>>>>>>>>> to
>>>>>>>>> pick up a change in proxy the blueprint top level pom
will need to
>>>>>>>>> be
>>>>>>>>> modified to point to proxy 0.4-SNAPSHOT.
>>>>>>>> I would assume this means "depends on modified API" and does
>>>>>>>> mean
>>>>>>>> "depends on some bug fixed in the implementation", right
>>>>>>> If you're referring to the semantic meaning attached to moving
>>>>>>> 0.3 to 0.4 then I think that would be taking this discussion
in a
>>>>>>> different direction. But that is a good point. Before getting
into a
>>>>>>> semantic versioning discussion, I think the intent of this was
to so
>>>>>>> if there are broken tests in 0.4-SNAPSHOT of a module which are
>>>>>>> by pulling in 0.4-SNAPSHOT of its dependency then its dependency
>>>>>>> should be updated.
>>>>>> No, this is not about semantic versioning (yet).
>>>>>> This is about the following: Consider bundle X depends on the API
>>>>>> org.apache.aries.y.api of bundle Y. Now some implementation of this
>>>>>> API
>>>>>> in package org.apache.aries.y.impl of bundle Y has a bug which must
>>>>>> fixed. In this case the dependency of bundle X on Y should not be
>>>>>> changed.
>>>>>> Regards
>>>>>> Felix
>>>>>>>> Regards
>>>>>>>> Felix
>>>>>>>>> This will lead us towards being able to release by module
but it
>>>>>>>>> implies
>>>>>>>>> a change in development practice. I will make the pom
>>>>>>>>> locally
>>>>>>>>> and test them but I'd like to check that release-by-module
is still
>>>>>>>>> the
>>>>>>>>> goal and that you all think this is a reasonable way
to be able to
>>>>>>>>> achieve it.
>>>>>>>>> Zoė

Guillaume Nodet
Open Source SOA

View raw message