On Tue, Aug 12, 2008 at 4:21 PM, M.-A. Lemburg <[EMAIL PROTECTED]> 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 Py_ssize_t 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
