On Wed, 2013-12-04 at 12:28 -0800, Eli Bendersky wrote:
On Wed, Dec 4, 2013 at 11:47 AM, M.-A. Lemburg <mal@egenix.com> wrote: On 04.12.2013 20:07, Benjamin Peterson wrote: > 2013/12/4 Barry Warsaw <barry@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.