[Python-Dev] The end of 2.7

Brett Cannon brett at python.org
Mon Apr 8 16:25:11 CEST 2013


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>


More information about the Python-Dev mailing list