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 <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2011-08-23 16:11:10 CEST