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

RE: rc1 is DOA. What now? (was: 1.7.0-rc1 up for testing / signing)

From: Bob Archer <Bob.Archer_at_amsi.com>
Date: Tue, 23 Aug 2011 10:29:37 -0400

> On 08/23/2011 08:17 AM, Bert Huijben wrote:
> >> +1 to release as 1.7.0-RC1 as all tests pass for me. -0 to release as
> >> Subversion 1.7.0
> >
> > Ok, make that a -1 to release as Subversion 1.7.0
> >
> > Subversion working copies that contain 'svn lock'-style locks can't be
> > upgraded by our current upgrade code. (We are mixing two sqlite
> > handles in the upgrade code and the code that inserts a lock checks if
> > a node exists using a db handle that can't look inside the transaction
> > of the other handle)
> >
> > I'm working on a fix and a regression test. (Should be fixed in a few
> > hours)
> In IRC, it has been essentially agreed that rc1 is DOA per the bug reported
> (and since fixed) above. The question then becomes, "What do we do with
> RC1?" I've seen these suggestions:
> (1) Keep on truckin'. Release it as-is but with a note saying "By the way, this
> won't be the final release candidate.
> (2) Re-roll the thing with exactly the same content, and from the same magic
> revision, except with the version tags reading "beta 4" instead of "release
> candidate 1".
> (3) Dump the re-release, and focus on a "soon" rc2 instead.
> I'd like to register my preference for Option #3
> Option #1 -- releasing a release candidate that's not a candidate for release --
> just doesn't make any sense to me.
> Option #2 at least clears up the status of the release to better reflect what
> we know about its lifetime, but I fear we will feel obligated to put some
> "space" between this beta4 and our next real release candidate. This
> "space" would further delay the soak period for the release.
> Option #3 doesn't have either of these problems, and -- if we scheduled it
> for this Wednesday or Thursday -- gives us a little more time to address Bert's
> concerns (mentioned elsethread) that we haven't done proper justice to the
> STATUS backport review process. [ I think that's really just secret code for
> "Hey, nobody voted for my stuff!", but ... ;-) ]

I'm not sure why you guys would version a "release" and then skip it. The first release candidate that is "released" should be called RC1, no matter what revision it is built from. Your gonna confuse people.


> My goals are simple: I seek to minimize the administrative overhead we
> inflict on ourselves, minimize the number of publicized false starts our user
> base sees, and minimize further unnecessary delay to the release cycle.
> And maximize shareholder value! Oh, and have a pony! And cake ... that I
> get to eat, too!!
> --
> C. Michael Pilato <cmpilato_at_collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2011-08-23 16:30:24 CEST

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.