On Tue, Aug 23, 2011 at 9:53 AM, Bob Archer <Bob.Archer_at_amsi.com> wrote:
>> 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.
There isn't a single best way that works for all folks. Your strategy
works for you, and that's great.
In the past, we did recycle version numbers, even on release
candidates, and it proved troublesome, so we just decided not to.
> Funny, I'm not mad yet... or am I?
"We're all a little mad here." :)
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Received on 2011-08-23 17:01:55 CEST