[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