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: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
Date Thu, 22 Jun 2006 06:06:29 GMT
I don't quite understand what you are asking.  Can you rephrase?


Regards,
Alan

Jason Dillon wrote:
> Does this mean that the bulk of changes will be done on M.m branches 
> and only release + minor changes done on M.m.r branches?
>
> --jason
>
>
> On Jun 21, 2006, at 6:52 PM, David Blevins wrote:
>
>> We had this whole conversation last week, lots of good discussion was
>> had.  I'd prefer not to have to have it again.  Here is my exact
>> understanding of our consensus and would like to put it to a vote to
>> avoid reinterpretation of that consensus in the future.
>>
>> 1.   branches/x.y would be the branch for all x.y.z releases
>>
>> 2.   when a release is frozen, we spin off a branch with that *exact*
>>      name, as in branches/x.y.z, where z starts at zero and increments
>>      by one.
>>
>> 3.   at that time branches/x.y is immediately updated to version
>>      x.y.(z+1)-SNAPSHOT
>>
>> 3.   We cut releases from the frozen branch
>>
>> 4.   When a release passes final tck testing and final vote, the
>>      frozen branch is moved to tags
>>
>> We create a branch at freeze time for the following reasons:
>>
>> 1.  it takes *at least* one week from freeze to ship due to voting,
>>     tck testing and potential repeats of that process (re-cut,
>>     re-certify, re-vote).  There is no reason why work on x.y.z+1
>>     needs to be delayed -- only 52 weeks a year.
>>
>> 2.  stronger guarantee no one is updating the branch once frozen
>>
>> 3.  less likely that people and ci systems (continuum) will checkout
>>     and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which
>>     would need to be removed manually and may accidentally be
>>     distributed.
>>
>> 4.  it is currently very difficult to roll version numbers forward,
>>     entries here and there are often missed.  Far better to have
>>     branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
>>     than a few overlooked x.y.z final numbers that needed to go back
>>     to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
>>     back later if that process happens in the frozen branch.
>>
>>
>> Here is my +1
>>
>>
>> -- David
>>
>>
>>
>> On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:
>>
>>> After the branches/1.1 was moved to tags there was some question as 
>>> to what happened to the 1.1 branch.  At that time some kind soul 
>>> created a new branches/1.1.1.  No activity has occurred in that 
>>> branch and given that we'll need to define the release goals of 
>>> 1.1.1 soon I'd like to propose the following.
>>>
>>> After 1.1 is released:
>>>
>>> * Delete branches/1.1.1
>>> * Move branches/1.1.0 to tags/1.1.0
>>> * Copy tags/1.1.0 to branches/1.1.1
>>> * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
>>> * Start working on 1.1.1
>>>
>>> When 1.1.1 enters time for release
>>>
>>> * Move branches/1.1.1 to branches/1.1.1.0
>>> * Change version from 1.1.1-SNAPSHOT to 1.1.1
>>> * Create release candidate rc1
>>> * put out for a vote
>>> * get a successful vote with no respins :)
>>> * move from branches/1.1.1.0 to tags/1.1.1.0
>>>
>>> Based on all the confusion in the past I think this procedure makes 
>>> it clear what phase were in for the release as well as avoids 
>>> tagging and branching repeatedly.
>>>
>>> I'm looking for lazy consensus and not a formal vote.
>>>
>>> Matt
>>>
>>
>


Mime
View raw message