> On Tue, Aug 23, 2011 at 9:29 AM, Bob Archer <[email protected]> > 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
