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.">

(original) (raw)




On Sat, Apr 6, 2013 at 5:02 PM, Benjamin Peterson <benjamin@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.