On Wed, Dec 4, 2013 at 2:47 PM, M.-A. Lemburg mal@egenix.com wrote:
On 04.12.2013 21:28, 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.
Can you clarify on some specific interesting cases you ran into?
One example is users stuck on e.g. Zope 2.10 or Plone 3.3 (or even earlier). They cannot upgrade because they are using customized installations and don't have the knowledge or resources to upgrade the systems to later versions.
Writing intentionally unmaintainable software and being locked into it is a different issue than platforms providing long-dead Python versions. If you do bad things, you're going to have a bad time.