On Tue, Aug 23, 2011 at 10: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.
>
> Funny, I'm not mad yet... or am I?
>
>
Do you announce the availability of these "releases" on public mailing lists
and invite people to look at them before they are approved?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-08-23 16:56:36 CEST