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

Re: [PROPOSAL] Create the 1.7.x branch. Like, now.

From: Hyrum K Wright <hyrum_at_hyrumwright.org>
Date: Tue, 12 Jul 2011 09:42:35 -0500

On Tue, Jul 12, 2011 at 9:32 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> The issue tracker currently has *no* non-Serf-related blocker issues open.
> Per prior agreement, this effectively means that there are no known
> blockers, as we have a contingency plan for Serf already (un-default it).  I
> realize that we'd like to see the tracker sit quiet (blocker-wise) for a
> week or so before saying "ship the RC", but I think we need to face some
> realities:
>  - blocker-class bugs can -- and will -- crop up after we branch.
>  - blocker-class bugs can -- and will -- crop up after we release,
>    for that matter!
>  - there seems to be more dev activity on 1.8-aimed feature branches
>    than on the trunk.  Our "merge pain" threshold has shifted.
> So, with all of this in mind, I propose that we immediately branch 1.7.x and
> release beta-1.  We than allow an extra week before we fire off RC1 -- we
> need to ensure that CHANGES and any other release administrivia get wrapped
> up anyway.
> What to do about Serf?  I'd like to think that Greg could wrap up his work
> on the single remaining blocking issue in the next week or so.  I've already
> heard (via Hyrum) that he's essentially finished with the work, and just
> testing his changes at this point.   I do not know, though, what the status
> of the Serf 1.0 release is, which I *thought* was also a pre-requisite for
> making available many of the recent blocker-related fixes.  (Greg?)
> Anyway, I'm *not* proposing that we immediately revert to Neon as the
> default after branching.  That week of beta gives Greg (or whoever) one last
> chance to save the day for Serf.  But I strongly feel that we as a community
> need to declare an RC1 date and stick with it in the absence of absolutely
> critical failures in Subversion.  The fuzzy release date thing is great for
> the first, oh, two years of a release.  But let's get on with it, already.
> So, to clarify, I'm proposing the following:
>  * Branch 1.7.x now.
>  * Release beta-1 immediately after branching.
>  * Make a go/no-go call on Serf 7 days from now.
>  * Release rc-1 after making (and acting on, if necessary) the Serf
>    go/no-go call.
> What say we?

I agree with the above.

One question that I have is regarding housekeeping. Do we have any
actions which should be done on trunk (file renames, whitespace
cleaning, mergeinfo pruning, etc), which will improve our experience
when merging to the branch?

Received on 2011-07-12 16:43:10 CEST

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