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

Re: Our (in)ability to do releases?

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2006-07-10 18:20:15 CEST

On Mon, 2006-07-10 at 17:59 +0200, Erik Huelsmann wrote:
> Also, I said that we definitely should have released RC1 after the
> initial fix: it may not have been the perfect one, but it did work for
> that moment and the perfect fix could have been in RC2...

I'm seeing two issues raised by this thread:

1. We don't have beta tests for new-feature releases, only release
candidates. Something with a known release-blocking bug is not a
release candidate, so once we know about a release-blocking bug, we
can't get any tarball testing done until we fix it.

2. Our compatibility rules only allow desupport of feature based on the
(I'll make up terms here) catastrophe model rather than the slow
extinction model.

In the catastrophe model, we release an svn 2.x which is considered a
totally different product from svn 1.x. There's an upgrade path, but
there's no other requirement of compatibility. svn 1.x and 2.x can
perhaps be installed concurrently, just like svn 1.x and CVS can be
installed concurrently. This is what GNOME did between 1.x and 2.x.

In the slow extinction model, we declare a feature deprecated in release
1.x, and then remove it in release 1.(x+5) or something. Users are
expected to migrate away from desupported features over time. I think
this is more like how gcc works.

One of the drawbacks of the catastrophe model is that we are forced to
do a lot of work during a relatively short window. We say "okay, we
have enough things we want to do now that we're going to put out svn 2.x
in [six months, a year, whatever]" and in that window we have to code
*every* incompatible change we want to do in the next 5-10 years, since
we only want to pay the price of a major upgrade rarely. I think the
reason we've never seen a serious proposal towards 2.0 is that no one
believes we have the resources to pull off such a massive effort, or
wants to coordinate it if we do.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 10 18:21:19 2006

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.