[Python-Dev] Maintaining old releases

[M.-A. Lemburg]

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.

> 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 ?

> 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.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 13 2008)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611