[Python-Dev] The end of 2.7 (original) (raw)
Brett Cannon brett at python.org
Mon Apr 8 16:25:11 CEST 2013
- Previous message: [Python-Dev] The end of 2.7
- Next message: [Python-Dev] Updates to PEP 1 (PEP process meta-PEP)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sat, Apr 6, 2013 at 5:02 PM, Benjamin Peterson <benjamin at python.org>wrote:
Per my last message, 2.7.4 has at long last been released. I apologize for the long interval between 2.7.3 and 2.7.4. To create more determinism in the future, I will be soon updating PEP 373 with approximate dates of future 2.7 bugfix releases. I will be aiming for 6 month intervals.
This means we need to talk about how many more 2.7 releases there are going to be. At the release of 2.7.0, I thought we promised 5 years of bugfix maintenance, but my memory may be fuddled. At any rate, 2.7.0 was released in July 2010, which currently puts us within a few months of 3 years of maintenance. Over the past year, I've been happy to see a lot of movement towards 3 including the porting of important codebases like Twisted and Django. However, there's also no doubt that 2.x is still widely used. Obviously, there will be people who would be happy if we kept maintaining 2.7 until 2025, but I think at this juncture 5 total years of maintenance is reasonable. This means there will be approximately 4 more 2.7 releases. Thoughts?
Since this has ended up with roughly 50 responses, I'm going to try and summarize where things stand for my own benefit.
First off, core devs almost all seem fine with declaring an end date to maintaining 2.7 and seeing these last releases happen every 6 months (since Benjamin volunteered and I think Martin and Ned said they are fine with that as well and it's really their call). The question for EOL seems to be whether to do one more release after 3.4 goes out in early 2014 or to see 2.7 through until early 2015.
The other question seems to be whether we should lock down the branch so people don't think we will continue to accept patches and such (much like Georg has done with the 3.2 pre-commit hook).
So those two points -- where to draw the line and whether to mothball the branch -- seem to be the only open questions.
For me, I think a possible compromise might work out. What if we say python-dev will see patches backported until the release following 3.4, but after that the last two releases (which sees us into 2015 as Benjamin originally proposed) will only be patched by contributions from the community? IOW we make it very clear that python-dev considers themselves off the hook after 3.4 in terms of feeling obliged to backport any of their own code, but we are willing to examine and commit patches as provided by external contributors as long as they apply to all applicable branches. E.g. if someone wants something fixed in 2.7 after 3.4 is out they need to supply the patches for both 2.7 and 3.4 so that python-dev is doing nothing more than acting and gatekeepers on the repo and doing the commits on behalf of the patch writer. And then once the final 2.7 release is out we lock it down to make it abundantly clear that python-dev is entirely done with Python 2. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130408/d3bc0e05/attachment.html>
- Previous message: [Python-Dev] The end of 2.7
- Next message: [Python-Dev] Updates to PEP 1 (PEP process meta-PEP)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]