[Python-Dev] Re: Stability and change

[Guido van Rossum]

> 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/)