aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holly Cummins <holly.k.cumm...@googlemail.com>
Subject Re: Aries blueprint release timeline?
Date Thu, 29 Mar 2012 10:57:28 GMT


On 29 Mar 2012, at 11:06, Jeremy Hughes <hughesj@apache.org> wrote:

[snip]

> Sorry if this reply is a bit rushed. I'm on my Android
>
> On 28 March 2012 16:27, Holly Cummins wrote:
>>
>>
>>
>
>>
>> B. We have a policy of using the minimum version of a dependency in  
>> our
>> poms. That is, we only depend on snapshots of other Aries bundles  
>> when we
>> actually need unreleased function.
>
> I'm not sure this is completely adhered to. It's also difficult to  
> check to
> see whether it's being done correctly.

At the moment we definitely don't adhere to this, which is one of the  
reasons doing a release is so hard - we end up having to release a  
bundle's snapshot dependencies even if we don't need any new function  
from that snapshot.

How we check we stick to this in future is a good question, though.  
The versions plugin can produce a list of snapshot dependencies, which  
we could review occasionally, but that's pretty manual process.

Hopefully what might make it work is that changing poms to use  
snapshot dependencies is more work than *not* changing them, so as  
long as we're all lazy enough our poms should stay in the correct  
state. :)

[snip]

>
>>
>>
>>
>> Phase 1: We build twice in Jenkins, using the maven versions plugin  
>> (with
>> an include list of org.apache.aries.*) to ensure we build both a  
>> slice of
>> current code, and with the minimum versions. The artefacts we  
>> release are
>> the ones with the minimum versions, since these are the ones which  
>> can be
>> independently released and installed into a system with older  
>> versions of
>> other bundles.
> So in addition to our current build a new definition would do a mvn
> versions:use-latest or whatever the right one is to use the latest
> snapshots ... then it would do the normal mvn install etc?

That's what I had in my mind, yes. So we'll be confident that we'd get  
a Jenkins build break if changes to one bundle regressed tests for  
another bundle.

  [snip]
>>
>>
>>
>>
>>
>>>
>>>
>>>
>>>


Holly

Mime
View raw message