[Python-Dev] [python-committers] next beta (original) (raw)

Guido van Rossum guido at python.org
Wed Aug 13 04:57:58 CEST 2008

On Tue, Aug 12, 2008 at 4:21 PM, M.-A. Lemburg <mal at egenix.com> wrote:

First, I'd like to know why this discussion is happening on the committers list.

Python-dev is the right list for these things. I've adjusted the CC accordingly. On 2008-08-12 20:44, Martin v. Löwis wrote:

I am planning to offer a single file patch for 2.3 and 2.4. As far as one more 2.5 release, I don't think there's going to be many changes to the 2.5 branch between now and 2.6/3.0 final - although if there is, we'll obviously have to do another release. I would like to establish a tradition where, after some final bug fix release (e.g. for 2.5), further "mere" bug fixes are banned from the maintenance branch (and I did revert several bug fixes from the 2.4 branch). I'm not sure I agree with this policy. Can you elaborate on /why/ you want this? Because there won't typically be sufficient testing and release infrastructure to allow arbitrary bug fixes to be committed on the branch. The buildbots are turned off, and nobody tests the release candidate, no Windows binaries are provided - thus, chances are very high that a bug fix release for some very old branch will be worse than the previous release, rather than better. Second, I don't think this is true. People using those patch level releases will test and report bugs if they are introduced by such backports. Besides, developers backporting such changes are diligent enough to test their changes - they will usually have a reason for applying the extra effort to backport.

But then it's too late! If there's a regression in 2.5.3 we'd have to issue a brown bag release 2.5.4. That would be more work for the release managers and frankly we don't have enough release manager hours as it is. So the argument that bugs will still get reported doesn't add up to much. The point is to avoid introducing bugs in the first place.

I don't see any advantage in undoing already tested and committed patches to an older branch.

Note that Python 2.4 is still widely used out there. As an example, all the Zope and Plone installations run Python 2.4 and will continue to do so for quite a while.

And they do so because they want stability. I agree with the release managers that we should only issue security fixes for these platforms. Anything else adds the risk of breakage, i.e. instability.

And there's a reason for this slow uptake of Python 2.5: as more and more servers run 64-bit OSes, the Pyssizet changes cause serious trouble with Python C extensions that were not updated by their authors.

I'm not sure what that has to do with anything. The older releases have worse support for 64-bit platforms!

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

More information about the Python-Dev mailing list