On Tue, Aug 23, 2011 at 10:10 AM, C. Michael Pilato <cmpilato_at_collab.net>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
>
Of these options, I would also prefer option #3. That said, I am not sure
if I agree that this is not a legitimate RC. There are some known bugs. So
what? Was any data lost, were puppies harmed? Suppose we roll an RC2 now.
You do not think over the 4 week cycle there will not be another bug that
surfaces? We already had known bug fixes in STATUS when we rolled the
release candidate.
I guarantee if this upgrade bug surfaced after 1.7.0 we would take our
normal sweet time in rolling a 1.7.1. It is not like we would drop
everything and push out an immediate release to fix this. So why pull the
emergency brake and stop the RC?
If people really want this bug fixed in the final version than vote for it
in STATUS so that Hyrum can merge it into the final release that is issued.
This is not a fix that requires an API or other compatibility concerning
change.
Maybe this means I prefer your option #1 and just do not agree with how the
situation is being portrayed.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-08-23 16:24:15 CEST