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.