Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <449A8395.4030808@optusnet.com.au>
Date: Thu, 22 Jun 2006 21:48:37 +1000
From: Gianny Damour <gianny.damour@optusnet.com.au>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
MIME-Version: 1.0
To: dev@geronimo.apache.org
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.)
References: <4499D2EE.7050905@hogstrom.org>
 <89B5E6C4-169B-46D1-9D7A-933DCF8C4436@visi.com>
In-Reply-To: <89B5E6C4-169B-46D1-9D7A-933DCF8C4436@visi.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

+1

Gianny

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