What we have essentially found is that where we could basically get
away with an 18 month update cycle for improved network security
support (extended out to a few years by certain major platform
vendors), that approach *isn't* working when it comes to putting a
feature release into long term maintenance mode. I don't think the
situation isn't critical yet, but it's getting close, and I think we
need to deal with it within the 12 months (and preferably sooner than
that).

This PEP as written applies to both Python 2.x and 3.x, but the two situations are very different.  3.x is on a ~18 month update cycle, so why isn't the status quo acceptable there?  Python 2.x has less than 18 months of support left, so could it get by with a single exceptional release instead of a general relaxing of the rules? (if it were up to me, I'd call that release Python 2.8 instead of 2.7.7)  If this PEP is mainly about a one-shot update to the security components of Python 2.x, I'd like to see an explicit list of what is in scope for the update.
">

(original) (raw)


On Mar 22, 2014, at 9:17 PM, Ben Darnell <ben@bendarnell.com> wrote:

On Sat, Mar 22, 2014 at 8:55 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
What we have essentially found is that where we could basically get
away with an 18 month update cycle for improved network security
support (extended out to a few years by certain major platform
vendors), that approach \*isn't\* working when it comes to putting a
feature release into long term maintenance mode. I don't think the
situation isn't critical yet, but it's getting close, and I think we
need to deal with it within the 12 months (and preferably sooner than
that).

This PEP as written applies to both Python 2.x and 3.x, but the two situations are very different. 3.x is on a \~18 month update cycle, so why isn't the status quo acceptable there? Python 2.x has less than 18 months of support left, so could it get by with a single exceptional release instead of a general relaxing of the rules? (if it were up to me, I'd call that release Python 2.8 instead of 2.7.7) If this PEP is mainly about a one-shot update to the security components of Python 2.x, I'd like to see an explicit list of what is in scope for the update.

-Ben
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/donald%40stufft.io

As one of the instigators who convinced Nick to write this PEP I�m far less concerned
about back porting things to earlier 3.x releases than I am about getting things into
2.7 at this point. Going from 3.2 to 3.4 is not terribly difficult if it requires any work at
all. Going from 2.7 to 3.4 is often times a significant investment in resources that has
to be taken by \*every\* network using project.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA