Subversion 1.4.0-rc3 is up for testing and signing. The magic revision
This is the exact same package as RC2, the only difference being that
it was produced with Autoconf 2.59, rather than 2.60. This eliminates
the deps build failures observed on RC2, and also reverts the main svn
source tree to a version of Autoconf known to be mature and work
properly, rather than use a new and potentially broken release.
The decision to reroll came after a long and unfinished debate on what
to do about the rc2 being rolled with autoconf 2.60. After roughly
one afternoon of discussing, we failed to reach an agreement, and
following a suggestion that the RM is the benevolent dictator of a
release, I made my mind up and rerolled.
This, unfortunately, invalidates the signatures made on RC2. I
apologize to all those who did sign that RC for wasting your time,
both real and cpu, on testing the previous release, but I really feel
that changing versions of the build system is serious enough to
warrant rerolling now, not in two weeks. Call me Susan if you
disagree, I do see the case against rerolling, but I'm tired of the
debate and just want to move on now.
Peter Samuelson remarked on IRC that if you *really* don't want to do
a full retest, you could just run a diff between rc2 and 3, verify
that there is no code change aside from autoconf stuff and
svn_version.h, and sign rc3 based on that. I would honestly prefer
that you do at least one test run with the new build system, but if
you really feel strongly against doing so, consider signing this way
over not signing at all (but mention that you didn't run the tests in
your sig email please, so that I know what kind of coverage there is).
So, thank you autoconf for breaking your code in a minor release,
thank you for providing the grounds for a thoroughly unpleasant
afternoon. Now, let's get on with it.
As usual, signatures from full committers back to me, and enthusiastic
tester feedback is welcome. However, this RC is not yet blessed for
wide release, so please don't make it available to people not
interested in test-driving the new release.
Also, distro package maintainers, please to NOT include any RC builds,
even blessed, into operating system distros. The reasons for not
doing so were very eloquently outlined by Karl in a mail, which is
summarized at the above address.
The quick version is: we don't guarantee compatibility between the RCs
and the final release, so if people install the RC, all their
repositories and working copies might break unrepairably when they
upgrade to 1.4.0 proper. We don't want that kind of bad publicity,
and neither do you.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Jul 15 20:44:31 2006