geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: [CONSENSUS?] Preparation for M4 -- branch early
Date Tue, 05 Jul 2005 03:44:42 GMT
I'm not a big fan of performing development on a branch that, IMO, 
should be frozen for QA.  I'm not sure if that's what people are 
proposing but, I just wanted to say that.


Regards,
Alan

On 7/4/2005 7:46 PM, David Blevins wrote:

>Do we have a consensus that we should branch at the beginning of the release cycle instead
of at the end as we have done in the past?
>
>If so, going to put out an email titled "M4 - 24 hour notice of branch", which I think
would be a good release practice.
>
>-David
>
>On Mon, Jul 04, 2005 at 07:15:34PM -0700, David Blevins wrote:
>  
>
>>On Mon, Jul 04, 2005 at 06:38:23PM -0700, Jeremy Boynes wrote:
>>    
>>
>>>David Blevins wrote:
>>>      
>>>
>>>>On Mon, Jul 04, 2005 at 05:22:36PM -0700, Jeremy Boynes wrote:
>>>>
>>>>        
>>>>
>>>>>David Blevins wrote:
>>>>>
>>>>>          
>>>>>
>>>>>>Anything I missed?
>>>>>>
>>>>>>            
>>>>>>
>>>>>SNAPSHOT elimination so the build is reproducible.
>>>>>          
>>>>>
>>>>Right.  Missed that one for M3 IIRC.
>>>>
>>>>
>>>>        
>>>>
>>>>>Branch so that M4 can stabilize whilst other changes are being made.
>>>>>          
>>>>>
>>>>We do for every milestone.  Don't expect this to be different.
>>>>
>>>>
>>>>        
>>>>
>>>>>Acceptance test process - how do we know what works (need to avoid a 
>>>>>broken release like M3).
>>>>>          
>>>>>
>>>>That's what I meant by:
>>>>
>>>> DB> We have a number of people interested in testing.  I'll ping
>>>> DB> them when I have something ready.
>>>>
>>>>Was thinking to branch when I dish out the binaries for testing.
>>>>Rather than the "surprise, here is a binary" approach we've done in
>>>>the past.  Sounds pretty much like what you are proposing as well.
>>>>
>>>>        
>>>>
>>>Yes - in the past we've just tagged and moved on. This time I think we 
>>>should create the branch at the start of the process rather than at the 
>>>end as there seem to be a lot of pent up changes planned. Yes, we may 
>>>need to merge some critical changes back to this branch but hopefully 
>>>this can be kept to a minimum.
>>>
>>>So basically,
>>>* create a branch now, say 1.0-M4-prep
>>>* do the stuff we talking about now on that branch
>>>* cut the final M4 distro
>>>* drop the 1.0-M4-prep branch
>>>
>>>Other work can continue on the trunk without destablizing the M4 release.
>>>
>>>      
>>>
>>+1 That's pretty much what I had in mind.
>>
>>
>>-David
>>    
>>



Mime
View raw message