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 05:53:58 GMT
David Blevins wrote:
> The only thing done in a branches/x.y.z made from branches/x.y is the 
> release process itself.  
I don't quite understand what this means.  Sorry.
> When we agree we look good enough to cut and run, we freeze, make the 
> branch and put together a release candidate.  At the point of the 
> freeze the release manager owns the branches/x.y.z till the vote 
> passes.  That's the ideal scenario anyway.
>
> -David
>
> On Jun 21, 2006, at 9:40 PM, 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