[Python-Dev] Maintaining old releases

M.-A. Lemburg mal at egenix.com
Thu Aug 14 12:03:56 CEST 2008


On 2008-08-14 08:43, Martin v. Löwis wrote:
>> For example, let's project dates for closing 2.6 and 3.0 now, and add
>> them to PEP 361.
> 
> My view is that they should be closed when 2.7 and 3.1 are released.

Since we don't have a fixed release cycle, making the 2.(n-1)
maintenance time frame depend on the 2.n release is not a reliable way
of defining the 2.(n-1) lifetime.

Instead, we should fix the dates based on the 2.(n-1) release date.

> Following another informal policy, we were going for an 18 months
> release cycle at some time (2.6 clearly took longer), which would
> mean that those branches get closed on March 1, 2010. Security
> releases will be available until October 1, 2013.

That would only allow 1.5 years for bug fixes - we were discussing
3 years for bug fixes and another 2 years for security fixes, ie.

2.6 bug fixes until      Oct 01 2011

2.6 security fixes until Oct 01 2013

Ditto for 3.0.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 14 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


More information about the Python-Dev mailing list