> 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
At my shop we don't tag our releases until they are approved for release. So, if we are working on 1.0Beta1 and find a problem we don't just make changes and call it Beta2 we fix the pre-release issues and build the beta from a later revision. Once it is approved to release we tag it 1.0Beta1 and release it.
Funny, I'm not mad yet... or am I?
BOb
Received on 2011-08-23 16:54:34 CEST