On Wed, 2013-12-04 at 12:28 -0800, Eli Bendersky wrote: > > > > On Wed, Dec 4, 2013 at 11:47 AM, M.-A. Lemburg <m...@egenix.com> wrote: > On 04.12.2013 20:07, Benjamin Peterson wrote: > > 2013/12/4 Barry Warsaw <ba...@python.org>: > >> On Dec 04, 2013, at 07:15 PM, Antoine Pitrou wrote: > >> > >>> As for the question, I think we should wait at least two > or three years > >>> before "sunsetting" 2.7. > >> > >> I've been thinking we should move Python 2.7 to > security-fix only around the > >> Python 3.5 time frame, with a couple more years of promised > security support. > > > > FWIW, the current plan is to have the last normal release in > 2015 and > > security releases "indefinitely" (2020 or something like > that). > > > Just as data point: we have customers that still request > Python 2.4 > compatible versions of our products - simply because they > cannot > upgrade. The last release of that series was in 2008. > > > I was always curious about these "cannot upgrade" cases. Most of the > time, they seem to boil down to "because that's the default Python our > RHEL comes with", completely ignoring the possiblity of just building > a newer Python locally and/or carrying along with the product.
FWIW Red Hat also now has a RH-supported way of running more recent versions of Python on RHEL: http://developerblog.redhat.com/2013/09/12/rhscl1-ga/ though I believe that's only supported on RHEL6 onwards (giving 2.7 and 3.3. on RHEL6). Doesn't help on RHEL 5 (which is still 2.4), though there are (unsupported) srpms available for later releases there. _______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
