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

Re: freebsd subversion port

From: <kfogel_at_collab.net>
Date: 2005-11-24 18:29:48 CET

Ben Collins-Sussman <sussman@red-bean.com> writes:
> On 11/24/05, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
> > > A few of us just learned that you published the subversion 1.3.0-rc2
> > > tarball into the FreeBSD ports tree. I wanted to let you know that
> > > this was a mistake, and to clarify why.
> >
> > Does this apply to Mandriva as well? ('cooker' has a 'Subversion 1.3.0'
> > package that's been through -rc2, -rc3, and -rc4, none of which have
> > actually been released).
>
> Yes, it applies to cooker as well. I'm not sure what cooker's policy
> is -- whether they consider it normal to distribute beta-test software
> or not. But even if they do, the fact still remains that the
> subversion project itself hasn't yet approved *any* 1.3 release
> candidates yet, even for testers!

It is almost *always* inappropriate for a third-party packager to
distribute Subversion release candidate tarballs to the public via the
packaging system, whether or not the RC has collected enough
signatures to be blessed as an official candidate.

The only exception I can think of would be if the entire distribution
is meant specifically for beta-testing upstream packages, and the
users of that distro are made aware of the dangers. And even in those
rare cases, a Subversion RC that hasn't collected enough signatures to
be an official RC is still off-limits; there are *no* exceptions to
that rule.

So packagers, please Don't Go There, okay? Can we be any more clear?

Subversion release candidates are for testing only. We might have to
withdraw one to fix bugs, and fixing those bugs might involve changing
APIs, or changing a soft-upgrade strategy in the repository or working
copy formats. If some of the distros users had begun depending on the
new API, or had unknowingly soft-upgraded their repository or working
copy, then they'd be in for a very unpleasant suprise when the real
release comes out and doesn't have the same API anymore, or doesn't
use the same formats. Not only would Subversion suddenly "stop
working" for them, but there wouldn't be any convenient path to get it
working again, since no blessed Subversion release would have the code
needed to interpret their legacy data.

We encourage RC testing by users who know how to install from a
tarball independently of their OS's packaging system. Those who stick
with a packaging system, however, should get only officially released
Subversions. Anything else is playing with fire. When the inevitable
blowup happens, both your reputation as a packager and Subversion's
reputation will suffer -- but only one will deserve it.

-Karl

-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 24 19:52:05 2005

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.