[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 1.7 Release Plan

From: Stefan Sperling <stsp_at_elego.de>
Date: Thu, 29 Jul 2010 11:59:40 +0200

On Wed, Jul 28, 2010 at 09:43:13PM -0500, Hyrum K. Wright wrote:
> On Wed, Jul 28, 2010 at 6:28 PM, Talden <talden_at_gmail.com> wrote:
> >> It looks like we might be fairly close to having on-disk formats
> >> stabilized, and hence rolling alphas. †Prereleases may be fairly
> >> prolific, since I want to work the bugs out of the transition to ASF
> >> distribution infrastructure, and get fixes into the hands of users
> >> rapidly.
> >
> > I'm very interested in experimenting with the alphas. †I have little
> > time or interest in building subversion myself (last time I looked at
> > that in ~1.3 days, getting the appropriate tools, dependencies and
> > environment set up was like gnawing off my own leg) but I'd very much
> > like to perform some scripted experiments using our corporate
> > repository content (a copy of course) with 1.7 on Win32 and Win64.
> The project doesn't typically provide binaries, partly because there
> are so many different combinations that it's hard to justify which
> ones to build and which not too.

I don't think deciding what platforms to build for is a problem.
The answer is simply "as many as we can".

Past experience has shown that if we only provide source releases,
then virtually nobody will test them. And that has resulted in several
problems not being found before release.
Interested readers might want to take a loot at this talk given at
Subconf 2009 by Hyrum and myself:

Because of the substantial changes done for 1.7, we will need pre-release
testing more than ever. So doing source-only 1.7 preview releases would
pose a major problem. We will have to actively push for pre-release
testing by providing binaries.
> However, providing binaries of these releases may be really useful,
> especially for people in your position. I *really* hope that our
> volunteer packagers chose to build binaries of these interim releases
> (with the appropriate warnings, of course). It would also be nice if
> third-parties (such as Tortoise) used these as part of their own beta
> processes.

I'll raise my hand.

The Subversion project has much closer ties to various Linux distributions
now than it had around the time of the 1.6 pre-release phase. This is partly
due to efforts by elego -- we actively help out with the official Debian,
Ubuntu, and OpenSUSE packages. I also maintain OpenBSD packages in my spare
time for the few folks who need them because they are crazy^Wsensible
enough to run OpenBSD.

For the platforms mentioned above, I will try to push for 1.7 binaries
during all phases of pre-release testing (alpha, beta, rc).
To encourage wide testing, the plan is to make these available in
conveniently installable form:
 - launchpad PPA archives for Ubuntu
 - special add-on repositories for Debian (possibly hosted at elego,
   unless we can find a better location somewhere Debian-related)
 - OpenSUSE build service RPM archives for OpenSUSE
(Hyrum, it would be great if we could synchronise such that links to binary
package archives for various systems become part of the pre-release

Obviously, the standard source-distribution pre-release disclaimer will
apply to the pre-release binaries as well. They won't be pushed into the
distribution's standard set of packages during pre-release phase.

I hope others will join the effort and help provide binary packages for
additional platforms (Windows comes to mind).

And I hope that our users will take these efforts seriously, and test the
1.7 pre-releases on non-production data in near-production environments
as much as possible. That would help everyone in this community (developers
and users) a whole lot.

But of course, even with a lot of testing, 1.7.0 likely won't be free of
known issues. We'll always have to live with a certain amounts of bugs in
every release, or we could never make a release. But we'll need an
exhaustive list of known problems to base our prioritizations on. And
wide testing will provide that.

I hope this will work out well and benefit the project.
If it does, we should consider doing the same for all future 1.x releases.

Received on 2010-07-29 12:00:25 CEST

This is an archived mail posted to the Subversion Dev mailing list.