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 ... ;-) ] 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 <[email protected]> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
