[Python-Dev] Re: Stability and change (original) (raw)

Guido van Rossum guido@python.org
Mon, 08 Apr 2002 18:00:58 -0400

It seems like adopting a Linux-style development branch makes lots of extra work and doesn't buy Python much extra testing or stability.

I'm not at all convinced that we should do this, but I don't think the work is that much. We've got long-lived branches for the 2.1 and 2.2 maintenance releases already.

What you're calling experimental releases, we currently call cvs checkout :-). I'm happy to keep truly experimental stuff in CVS between releases and aim for stability with each 2.x / minor release.

If I believed there was a way to get more people to experiment with fresh code, I'd do it. I had thought that CVS is too high of a barrier, but I think we probably get as much from testers who are running CVS as we get from testers who are downloading alpha and beta releases.

The more releases we do, the more time wasted on packaging of the releases and building docs and installers.

One of the suggestions on the table is to seriously streamline the work we do for a "release" -- perhaps with the exception of "major releases" (which are really "minor" releases: 2.1, 2.2, 2.3). In particular, we would not build a Doc release and a Windows installer for each micro release, nor a Mac release.

We make bug reporting more complicated, because we need to check what CVS version corresponds to 2.3.17.

Don't you know how to use CVS or something? We have tags for each release -- if there's a question about this, it's always easily answered.

And, as Barry just noted, we lead users to make complicated statements like: "This works with Python versions 2.4.3-2.4.19 and 2.6.0 on up but not 2.5.0-2.5.18."

Apparently that's not a problem for Linux. I'd say that since nobody except bleeding edge developers uses a 2.5.x, all you'd have to say would be "this works on 2.4.3 and newer stable releases".

--Guido van Rossum (home page: http://www.python.org/~guido/)