aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From zoe slattery <>
Subject Re: Release by module - changes to trunk
Date Tue, 01 Feb 2011 15:17:03 GMT
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.
> 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.
> 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?
> 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 all 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
>>>>>>>> switch
>>>>>>>> to a dependency on the development version.
>>>>>>>> So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce
>>>>>>>> proxy
>>>>>>>> 0.3, testsupport 0.3 and  parent 0.3. If blueprint 0.4-SNAPSHOT
>>>>>>>> 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
not mean
>>>>>>> "depends on some bug fixed in the implementation", right ?
>>>>>> If you're referring to the semantic meaning attached to moving from
>>>>>> 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
>>>>>> semantic versioning discussion, I think the intent of this was to
>>>>>> if there are broken tests in 0.4-SNAPSHOT of a module which are fixed
>>>>>> 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 be
>>>>> 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 changes
>>>>>>>> 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ƫ

View raw message