[Python-Dev] Re: Stability and change
Guido van Rossum
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
> 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
> 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/)