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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4