On Sat, Mar 22, 2014 at 8:55 PM, Nick Coghlan <ncoghlan at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20140322/9949451e/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4