[Python-Dev] Maintaining old releases (original) (raw)

Steve Holden steve at holdenweb.com
Wed Aug 13 15:20:29 CEST 2008

M.-A. Lemburg wrote:

On 2008-08-13 07:53, Martin v. Löwis wrote:

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. They might be using releases, but they are not using the subversion maintenance branches. Do you know anybody who regularly checks out the 2.4 maintenance branch and tests it? So at best, people will only report bugs after the release was made, meaning that there is a realistic chance that the release itself breaks things. I think that's an overly pessimistic view. There's always a chance of breaking things when patching anything - whether that's a security fix or a fix for a bug that's hard to work around in an application using Python. Note that those fixes will usually be backports from a more recent release, so even if they don't receive enough direct testing on the older branch before the release is cut, they will get their share of testing either in the context of the more recent branch. I'm not a great believer in "indirect testing" of this kind.

As for using the releases themselves: there have been 80462 downloads of 2.4.5 since it was released in March, as compared to 517325 downloads of the 2.5.2 MSI in July alone. So I'm skeptical that many people do actually use the 2.4.5 release. It's difficult to use such download numbers as hint for the number of deployed installations. 2.4.5 was not released as binary, so interested parties had to compile that version by themselves and those installations don't show up in your statistics. I'm sure that if we had released binaries as well, the number would have looked different, esp. if you only look at the Windows binaries.

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. My problem is that this backporting is not systematic. It's arbitrary whether patches get backported or not. Part of the problem is that it is/was also unclear whether there ever will be another release made out of 2.4. That's a valid point, but does this really warrant backing out changes that have already been applied ? Isn't it better to get at least some bugs fixed rather than to not fix them at all ? No, given that (in teh USA in 1999, anyway) there's a 7% chance that a bugfix will inject a new problem. That chance goes up when testing is minimal - testing of later releases doesn't validate untested amendments to earlier releases.

When 2.4.4 was released, Anthony announced, in

http://mail.python.org/pipermail/python-dev/2006-October/069326.html "This will be the last planned release in the Python 2.4 series" So anybody committing to the 2.4 branch after that should have expected that the patches will never get released. Perhaps we should just document the maintenance of Python releases more clearly and also plan for a final bug fix release 3 years after the initial branch release. That way developers and users can also adjust their plans accordingly. As always the problem is getting someone to do this not insignificant amount of work.

regards Steve

Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/

More information about the Python-Dev mailing list