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