[Python-Dev] Maintaining old releases

[Steve Holden]

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/