I think moving from branches to tags and back again is too disruptive. The reason it sits in its
own area in branches is so that it can be finalized and then copied once its done. If we have to
then we have to but this should be the rare exception that something is caught after the final vote
has been cast.
Aaron Mulder wrote:
+1, but if we cut a release from the frozen branch, we need to note
the SVN version number or something so when we move it to tags we're
absolutely sure we didn't catch an extra commit in the tag. I'm also
fine with copying to tags, making the candidate from tags, and then
recreating the tag if another release candidate turns out to be
necessary.
Thanks,
Aaron
On 6/22/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
Okay, then +1
--jason
On Jun 21, 2006, at 10:19 PM, David Blevins wrote:
> The only thing done in a branches/x.y.z made from branches/x.y is
> the release process itself. 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
>>>>
>>>
>>
>
