On Wed, Dec 4, 2013 at 2:47 PM, M.-A. Lemburg <m...@egenix.com> wrote:
> On 04.12.2013 21:28, 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. > > > > 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.
_______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
