[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Branching 1.6.x this week

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Mon, 10 Nov 2008 11:16:12 -0600

Greg Stein wrote:
> Why not keep it on trunk and simply say "no destabilizing work. go to
> a branch" ?

Mainly because I don't trust people (myself included) to follow that mandate.

> Once you branch, then you'll get less traffic on it. And branching
> with *known* work simply screams "too early" to me. I mean... if we
> know it isn't good enough for 1.6, then why branch and pretend it is?

I'm tired of playing bug whack-a-mole on trunk while waiting to branch.

I think we've gotten to the point were we have a number of different features in
various stages of development. That's great, but it also introduces problems,
one of which is that trunk is generally a bit more unstable these days than it
has been in the past. Rather than waiting for the stars to align and trunk to
get stable, let's branch and start stabilizing a known feature set on the
branch, instead of a moving target on trunk.


> On Mon, Nov 10, 2008 at 8:57 AM, Hyrum K. Wright
> <hyrum_wright_at_mail.utexas.edu> wrote:
>> [second verse, same as the first...]
>> Alright folks, we're branching 1.6.x this week. Here's the schedule of events:
>> Nov. 12, ~1700 UTC: Create 1.6.x branch from current trunk.
>> Nov. 12, sometime in the evening: Roll 1.6.0-pre1 and get some sigs.
>> Nov. 13: release 1.6.0-pre1
>> I know that we've still got some stuff in the TODO file, but it feels like it
>> isn't anything which can't happen on the branch (glasser, I haven't forgotten
>> about the FSFS stuff. :) ) Also, trunk is generally looking more stable now,
>> and by branching, we can work on stabilizing the branch independent of any
>> destabilizations going on in trunk.
>> I propose that the -preN releases don't require the full signature complement,
>> and that we release them *even with known* issues, while enumerating those
>> issues as part of the release. I also propose that we use the looser voting
>> guidelines while still doing -preN releases to aid code mobility into the branch
>> (while still getting a second set of eyes on it). These changes mirror what we
>> did early in the 1.5.x release cycle.
>> Objections?
>> -Hyrum

Received on 2008-11-10 18:16:31 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.