[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: Hyrum K Wright <hyrum.wright_at_wandisco.com>
Date: Tue, 23 Aug 2011 09:45:38 -0500

On Tue, Aug 23, 2011 at 9:29 AM, Bob Archer <Bob.Archer_at_amsi.com> wrote:
>> 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.

We're going to confuse people if we *don't* skip RC1. Version numbers
are cheap, and we've already labelled something (in both the
repository and our own craniums) as RC1. If we create *another* RC1,
every time somebody references an "RC1" we have to ask "which one?"
That way lies madness....

-Hyrum

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Received on 2011-08-23 16:46:13 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.