On 31 January 2011 13:23, Felix Meschberger <[email protected]> wrote:
> Hi,
>
> (from the peanut galleray again ;-)
>
> Am Montag, den 31.01.2011, 11:17 +0000 schrieb zoe slattery:
>> Hi all
>>
>> Now that we have a 0.3 release I plan to change trunk so that where
>> modules depend on other Aries modules the depend on the released
>> versions and _not_ versions in trunk.
>
> Great.
>
>>
>> This will mean:
>>
>> (a) The current development version will be 0.4-SNAPSHOT
>> (b) All Aries 0.4-SNAPSHOT modules will depend on 0.3 parent.
>> (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 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 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 fixed
by pulling in 0.4-SNAPSHOT of its dependency then its dependency
should be updated.

>
> 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 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ë
>>
>>
>>
>
>
>

Reply via email to