On 6/22/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
Thanks David, I tried to recap in the other thread and didn't receive any
additional responses so
now that we have a branches/1.1.0 branches/1.1 and a branches/1.1.1 I don't
think we quite nailed
it. Your summary is great and I concur.
Here is my + 1 and I'm happy to get the Wiki updated.
The remaining question is what to do with the branches that are out there. I
think we should whack
what's out there (does not appear that there has been any activity)
branches/1.1 and branches/1.1.1.
When the vote is complete later today and we release 1.1 I'll move
branches/1.1.0 to tags/1.1.0
and then make the copy to branches/1.1 and update the versions to
1.1.1-SNAPSHOT as well as the
plugin releases.
+1
Then I think we're open for G-Business.
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
>>
>
>
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
