The Python 2 death march
![](https://secure.gravatar.com/avatar/cd2e442c42c95ed534e4197df4300222.jpg?s=120&d=mm&r=g)
Hi all, It's finally time to schedule the last releases in Python 2's life. There will be two more releases of Python 2.7: Python 2.7.17 and Python 2.7.18. Python 2.7.17 release candidate 1 will happen on October 5th followed by the final release on October 19th. I'm going to time Python 2.7.18 to coincide with PyCon 2020 in April, so attendees can enjoy some collective catharsis. We'll still say January 1st is the official EOL date. Thanks to Sumana Harihareswara, there's now a FAQ about the Python 2 sunset on the website: https://www.python.org/doc/sunset-python-2/ Regards, Benjamin
![](https://secure.gravatar.com/avatar/75e9a11371cbe1566607180863efdf4c.jpg?s=120&d=mm&r=g)
Maybe I'm not involved enough in the release process, but this seems confusing to me. On the same day that the PSF put up a page about the 1/1/2020 date, we choose April 2020 as the last release? Why? I thought the point was to save core devs efforts. Is this an unofficial grace period? Will there be a public document that announces the April date? What does the "official EOL date" mean if there's a release in April? --Ned. On 9/9/19 9:29 AM, Benjamin Peterson wrote:
![](https://secure.gravatar.com/avatar/cd2e442c42c95ed534e4197df4300222.jpg?s=120&d=mm&r=g)
On Tue, Sep 10, 2019, at 15:54, Ned Batchelder wrote:
This mail is a public document. The thinking is that ±2 months is rounding error in Python 2's lifetime, so why not move it to a significant community time? (There was never going to be a release exactly on January 1 simply because it's an inconvenient time of the year for "work".) I suppose practically it amounts to a small grace period if core devs willing to merge 2.7 changes post 2020-01-01 can be found.
![](https://secure.gravatar.com/avatar/75e9a11371cbe1566607180863efdf4c.jpg?s=120&d=mm&r=g)
On 9/10/19 11:06 AM, Benjamin Peterson wrote:
I'm not looking forward to answering questions from the public about why the PSF is writing dire and specific warnings like "We have decided that January 1, 2020, will be the day that we sunset Python 2," while the core devs are planning a release four months after that. It won't help Python's credibility, and may convince some people that they don't have to take the date seriously.. --Ned.
![](https://secure.gravatar.com/avatar/d67ab5d94c2fed8ab6b727b62dc1b213.jpg?s=120&d=mm&r=g)
On Wed, Sep 11, 2019 at 5:05 AM Ned Batchelder <ned@nedbatchelder.com> wrote:
It always takes some time to go through the phases of a release. If the final release happened on Jan 1st, there wouldn't be time to get patches in during the tail of 2019. Python 2's sunset does indeed happen as 2020 starts, but before night completely falls, there are some final actions to be taken in order to produce one good, clean, final release. Plus the whole "let's align it with something else that's happening" thing, but that doesn't sound half as grand :) ChrisA
![](https://secure.gravatar.com/avatar/cd6aae9615c3b36130e2470902833a72.jpg?s=120&d=mm&r=g)
On Tue, Sep 10, 2019 at 10:03 PM Ned Batchelder <ned@nedbatchelder.com> wrote:
To me it seems pretty clear: On Jan 1st 2020, the 2.7.x branch will no longer receive fixes for any *new* bugs or security issues, nor other improvements. I would expect that be the time of the code freeze for the first release candidate, not the time of the final release. While we will still fix issues *introduced in 2.7.18 since 2.7.17* before the final 2.7.18 release, we won't address any other bugs or security issues and won't backport anything *new* from 3.x. (I may have some details not exactly correct here, but I hope the gist is correct.) I'm sure the wording could be improved, but generally this seems entirely reasonable to me. - Tal Einat
![](https://secure.gravatar.com/avatar/b2051833183f6ff9a789b01536b1b201.jpg?s=120&d=mm&r=g)
*RE: Ned's comments -- *That is the same reaction I had when I read through this thread. *RE: Tal's comment - *I could see this making sense as an explanation. *RE: Guido's comment* This makes me think that April 2020 is not a thing. And if Ben is supporting solo, then can people email him directly with issues? 😂😂😂 *On a serious note...* I would like clarification, so we (dev community and PSF) have a shared understanding of the direction and are sending the same messaging. -Jackie PSF Board of Directors On Tue, Sep 10, 2019 at 4:20 PM Tal Einat <taleinat@gmail.com> wrote:
-- Jacqueline Kazil | @jackiekazil
![](https://secure.gravatar.com/avatar/01aa7d6d4db83982a2f6dd363d0ee0f3.jpg?s=120&d=mm&r=g)
I think it’s fine to say that Python 2 EOL is on January 1, 2020. That doesn’t preclude a Contractual Obligation release in April. There’s precedence in the last Python 1 (1.6.1) release! https://en.wikipedia.org/wiki/Monty_Python%27s_Contractual_Obligation_Album -Barry
![](https://secure.gravatar.com/avatar/2828041405aa313004b6549acf918228.jpg?s=120&d=mm&r=g)
I think Ned's concerns are real, and the sunset-python-2 page could use some wordsmithing to explain that even though support ends on Jan 1, there will be a wrap-up release some time after that, but it won't incorporate any changes made or proposed after Jan 1. Another place where that document could be improved is in clarifying the different uses of the word "volunteers". For me, that's the most confusing part as I was reading it. As near as I can tell, these are different groups, or at least largely disjoint: * "We are volunteers who make and take care of the Python programming language" * "most volunteers will not help fix them" * "If you need free help from volunteers" Unfortunately I'm heading out of town and don't have time to help clean this up. Eric On 9/10/2019 5:09 PM, Jacqueline Kazil wrote:
![](https://secure.gravatar.com/avatar/342e4889fd14e21376a870e9d9ffc5d9.jpg?s=120&d=mm&r=g)
Hi. I've joined python-dev to participate in this thread (I don't have email delivery turned on; I'll be checking back via the web). Benjamin, I am sorry that I didn't check in with you, and assumed that January 1, 2020 would be the the date of the final 2.7 point release. (My understanding was based on Guido's EOL announcement from March last year https://mail.python.org/pipermail/python-dev/2018-March/152348.html -- I should have also gotten a review from you and not just the Steering Council in https://github.com/python/steering-council/issues/14 .) I'm going to continue this discussion here so I can make sure I understand the policy decision properly, and then (if necessary) update the FAQ. Based on what I've read here and what I see in https://www.python.org/dev/peps/pep-0373/#maintenance-releases , it sounds like the timeline will go something like: * 2019-10-19: release of 2.7.17 October * October, November, and December 2019: developers continue to fix issues in 2.7 * 2020-01-01: code freeze for 2.7.18 release candidate * January and February 2020: flexibility to fix any issues introduced since the 2.7.17 release, but no other bugs or security issues, and no 3.x backports * ~2020-04-02: release candidate for 2.7.18 * 2020-04-17: final 2.7.18 release Is this right? (If so, I can submit an update to PEP 373.) This is a little more complicated than I had anticipated when communicating out about the sunsetting. But I can find a way either to concisely communicate this, or to point to a user-friendly explanation elsewhere. Thanks. -- Sumana Harihareswara Changeset Consulting https://changeset.nyc
![](https://secure.gravatar.com/avatar/5dde29b54a3f1b76b2541d0a4a9b232c.jpg?s=120&d=mm&r=g)
Regardless of the date of the final release, no one's Python2 install will stop working, and people will still be able to download and install that last release. So I like the metaphor -- it's being "sunset" -- there will be a long dusk ...... a month or tow makes no difference to anyone's workflow. -CHB On Fri, Sep 13, 2019 at 6:39 PM Sumana Harihareswara <sh@changeset.nyc> wrote:
-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
![](https://secure.gravatar.com/avatar/cd2e442c42c95ed534e4197df4300222.jpg?s=120&d=mm&r=g)
On Fri, Sep 13, 2019, at 18:18, Sumana Harihareswara wrote:
Hi. I've joined python-dev to participate in this thread (I don't have email delivery turned on; I'll be checking back via the web).
sorry :)
Security issues will probably be fixed. At least, I wouldn't in abstract find that objectionable assuming someone wants to write a patch.
* ~2020-04-02: release candidate for 2.7.18 * 2020-04-17: final 2.7.18 release
I don't know if these will be the exact dates but probably close.
A succinct statement of the relevant information is: "After 10 years, the core developers of CPython are stopping development on the 2.7.x line. The last release will be in April 2020." If it's easier to communicate that the sunset of CPython 2 is April 2020, that seems fine with me. January 1 was a somewhat arbitrary date we put in the PEP when 2020 still seemed like a long way off but people wanted to know whether 2.7 would be released until 2021 or not. I was never going to make a 2.7 release literally on January 1. (Fighting with GPG would make short work of New Year's resolutions pertaining to temperance and strong language.) I failed to anticipate how strongly people would latch onto that exact moment in time as the end of Python 2. I additionally share the bemusement of some other commentators on this thread to the idea of Python 2 "support", which is not something ever promised to Python 2 (or 3) users by CPython core developers. Essentially, next year, we're changing our "support" policy of Python 2.7 from "none, but we're nice people" to "none".
![](https://secure.gravatar.com/avatar/880ac02012dcaf99f0392f69af4f8597.jpg?s=120&d=mm&r=g)
On 24/09/2019 04:21:45, Benjamin Peterson wrote:
I understand, but I hope that if a clear bug (perhaps especially a security bug) is found in Python 2.7 (perhaps one that is also in Python 3.x) the core devs will not be in principle opposed to fixing it. At least if one of them (or someone else sufficiently qualified) is prepared to do the work. Especially as you're "essentially" (and you ARE :-) -:) ) "such nice people". Best wishes Rob Cliffe
![](https://secure.gravatar.com/avatar/be200d614c47b5a4dbb6be867080e835.jpg?s=120&d=mm&r=g)
On 25Sep2019 2140, Benjamin Peterson wrote:
The biggest thing that will change is that all our CI systems will stop testing 2.7, and there's a good chance we'll lock (or delete?) the 2.7 branch from our repo. So you may find someone nice enough (or willing enough to accept money (or willing to accept enough money)) to fix an issue, but the fix will have to go somewhere other than the main repo and someone else will have to verify and release it. Cheers, Steve
![](https://secure.gravatar.com/avatar/addb93ccfcdb56a13a477192a7cf6a29.jpg?s=120&d=mm&r=g)
On Thu, Sep 26, 2019 at 1:58 PM Ethan Furman <ethan@stoneleaf.us> wrote:
Will there be a time delay between the final tagging and the deletion so any who would like the repo in its final state can clone it at that point?
No need; you can try this with any currently closed branch like 3.3: `git checkout -B 3.3 refs/tags/3.3` will check out a local `3.3` branch at the tag (resetting the `3.3` local branch if it already existed). The same will work for 2.7 after the branch is deleted.
![](https://secure.gravatar.com/avatar/d67ab5d94c2fed8ab6b727b62dc1b213.jpg?s=120&d=mm&r=g)
On Fri, Sep 27, 2019 at 5:04 AM Ethan Furman <ethan@stoneleaf.us> wrote:
If I've understood "tag" correctly, the commits should all remain in the repository for all time, so you should indeed be able to view it as of EOL. You can "git checkout v2.7.18" (or whatever the number is) after cloning the repository. ChrisA
![](https://secure.gravatar.com/avatar/5c3bcfa09d6365a980e775e65d2e0931.jpg?s=120&d=mm&r=g)
On Sep 26, 2019, at 14:50, Ethan Furman <ethan@stoneleaf.us> wrote:
Nothing will be lost, there's no need for a time delay. As we do for every release, there will be a tag created for the final 2.7 release of the form "v2.7.xx". That allows you to checkout the state of any release, including the final 2.7 release. At end-of-life time, we will also create a final "2.7" tag that reflects the final state of the 2.7, in case anything else was checked in following that last release. There will no longer be a "2.7" branch in the repo so it won't be possible to merge 2.7 changes back into the central repo. The 2.7 tag will act as sort of a read-only branch, i.e. you can still do: git checkout 2.7 to access it. If you want, you could create a local branch in your repo. See: https://devguide.python.org/devcycle/#end-of-life-branches -- Ned Deily nad@python.org -- []
![](https://secure.gravatar.com/avatar/342e4889fd14e21376a870e9d9ffc5d9.jpg?s=120&d=mm&r=g)
Per https://discuss.python.org/t/petition-abandon-plans-to-ship-a-2-7-18-in-apri... I have now: * written a PR to update PEP 373 to mark that the code freeze happened on 1 January https://github.com/python/peps/pull/1304 * updated the Python 3 Q&A http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_an... similarly https://bitbucket.org/ncoghlan/misc/pull-requests/21/update-python-3-q-a-to-... * added a "what happens now?" section to https://www.python.org/doc/sunset-python-2/ -- Sumana Harihareswara
![](https://secure.gravatar.com/avatar/342e4889fd14e21376a870e9d9ffc5d9.jpg?s=120&d=mm&r=g)
Benjamin: now that PyCon 2020 has been cancelled, are you considering releasing 2.7.18 slightly earlier? -- Sumana Harihareswara Changeset Consulting https://changeset.nyc
![](https://secure.gravatar.com/avatar/342e4889fd14e21376a870e9d9ffc5d9.jpg?s=120&d=mm&r=g)
On 3/27/20 12:49 PM, Sumana Harihareswara wrote:
Benjamin: now that PyCon 2020 has been cancelled, are you considering releasing 2.7.18 slightly earlier?
(I ask because: before you do that, I would like to submit some changes to the documentation for the 2.7 branch, to indicate to users that they ought to switch to Python 3.) Sumana Harihareswara Changeset Consulting https://changeset.nyc
![](https://secure.gravatar.com/avatar/342e4889fd14e21376a870e9d9ffc5d9.jpg?s=120&d=mm&r=g)
I'm sorry, I should have been more specific. I'm talking about the "switch to Python 3" banner that we need to add per discussion in https://github.com/python/steering-council/issues/3 . I am pretty sure it's not too late for that. -Sumana On 3/29/20 10:23 AM, Victor Stinner wrote:
![](https://secure.gravatar.com/avatar/342e4889fd14e21376a870e9d9ffc5d9.jpg?s=120&d=mm&r=g)
Thanks. I'm working to get https://github.com/python/steering-council/issues/3 resolved by April 17th to add an informational header to all the deep links within https://docs.python.org/2/* . I welcome help on the pull requests linked from that issue (such as https://github.com/python/cpython/pull/19229 ), and on the question Leonard Richardson asks there regarding https://github.com/python/devguide/blob/master/devcycle.rst .
![](https://secure.gravatar.com/avatar/342e4889fd14e21376a870e9d9ffc5d9.jpg?s=120&d=mm&r=g)
Benjamin or others: could you please review https://github.com/python/cpython/pull/19229 to "Add an optional obsolete header." to the 2.7 documentation today or tomorrow? Much thanks.
![](https://secure.gravatar.com/avatar/047f2332cde3730f1ed661eebb0c5686.jpg?s=120&d=mm&r=g)
It probably means that from January to April Benjamin will be too busy porting Dropbox to Python 3 to have time for Python 2 support. Or possibly it means that until PyCon 2020, there will be only one core developer supporting Python 2, and it will be Benjamin. You choose. :-) On Tue, Sep 10, 2019 at 4:00 PM Ned Batchelder <ned@nedbatchelder.com> wrote:
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
![](https://secure.gravatar.com/avatar/d6b9415353e04ffa6de5a8f3aaea0553.jpg?s=120&d=mm&r=g)
On 9/10/2019 10:54 AM, Ned Batchelder wrote:
What does the "official EOL date" mean if there's a release in April?
To me, it means that coredevs freely patching 2.7 ends 1/1/2020 and that the final release will occur by PyCon and that everything between the two is at the discretion of Benjamin, the release manager. I think that the first release candidate should be well before PyCon, maybe even in January, to make 2.7 EOL real and to allow time for a second or even a third, due to last minute pleas. But that is up to Benjamin. -- Terry Jan Reedy
![](https://secure.gravatar.com/avatar/e8600d16ba667cc8d7f00ddc9f254340.jpg?s=120&d=mm&r=g)
Stefan Behnel wrote:
It means we should all consider Python 2.7 EOL'ed come January 1 and Benjamin will make a release when it's convenient, and he just happens to know ahead of time that convenient for him is PyCon US 2020. :)
Also, what day in April? For example, planning the release for the 1st could possibly add further to the confusion.
PyCon US 2020 is mid-April, so if the release is going to coincide with the conference then it won't be at the beginning of the month.
![](https://secure.gravatar.com/avatar/c371bd9eebd30a2fa9a7253cb6be699d.jpg?s=120&d=mm&r=g)
Benjamin, what are you thoughts on usage of the "needs backport to 2.7" label? For most of the PRs I've reviewed I tend to avoid adding it myself, but I've seen it used periodically. It seems to be used rather infrequently ( https://github.com/python/cpython/pulls?q=is%3Apr+label%3A%22needs+backport+...), but I'm not entirely clear on when it should be used, particularly for documentation-related PRs. Also, is there an official date when the label will be removed? Removing the backport label seems to generally be at the discretion of the release manager for that version, but I was curious as to whether it would be removed on the sunset date or prior to then. Without the label, backport PRs can still be opened manually of course, but removing it would probably help to discourage 2.7 backports. On Mon, Sep 9, 2019 at 9:38 AM Benjamin Peterson <benjamin@python.org> wrote:
![](https://secure.gravatar.com/avatar/e8600d16ba667cc8d7f00ddc9f254340.jpg?s=120&d=mm&r=g)
Kyle Stanley wrote:
It should be used where appropriate. ;) It's a per-case thing where you have to balance backwards-compatibility with whatever you're changing. Plus you have to have someone doing the PR review who cares enough to deal with the (good) chance there will be a merge conflict in the backport.
![](https://secure.gravatar.com/avatar/cd2e442c42c95ed534e4197df4300222.jpg?s=120&d=mm&r=g)
On Wed, Sep 18, 2019, at 19:23, Kyle Stanley wrote:
I don't think the 2.7 backport label is currently overused. The 2.7 branch is already is a fairly quiet state. We've had less than 15 commits to 2.7 this month despite there being a week of more than 20 core developers intensely hacking on CPython. The label drives the automated backport tooling. There's no need to impede legitimate 2.7 backports.
![](https://secure.gravatar.com/avatar/75e9a11371cbe1566607180863efdf4c.jpg?s=120&d=mm&r=g)
Maybe I'm not involved enough in the release process, but this seems confusing to me. On the same day that the PSF put up a page about the 1/1/2020 date, we choose April 2020 as the last release? Why? I thought the point was to save core devs efforts. Is this an unofficial grace period? Will there be a public document that announces the April date? What does the "official EOL date" mean if there's a release in April? --Ned. On 9/9/19 9:29 AM, Benjamin Peterson wrote:
![](https://secure.gravatar.com/avatar/cd2e442c42c95ed534e4197df4300222.jpg?s=120&d=mm&r=g)
On Tue, Sep 10, 2019, at 15:54, Ned Batchelder wrote:
This mail is a public document. The thinking is that ±2 months is rounding error in Python 2's lifetime, so why not move it to a significant community time? (There was never going to be a release exactly on January 1 simply because it's an inconvenient time of the year for "work".) I suppose practically it amounts to a small grace period if core devs willing to merge 2.7 changes post 2020-01-01 can be found.
![](https://secure.gravatar.com/avatar/75e9a11371cbe1566607180863efdf4c.jpg?s=120&d=mm&r=g)
On 9/10/19 11:06 AM, Benjamin Peterson wrote:
I'm not looking forward to answering questions from the public about why the PSF is writing dire and specific warnings like "We have decided that January 1, 2020, will be the day that we sunset Python 2," while the core devs are planning a release four months after that. It won't help Python's credibility, and may convince some people that they don't have to take the date seriously.. --Ned.
![](https://secure.gravatar.com/avatar/d67ab5d94c2fed8ab6b727b62dc1b213.jpg?s=120&d=mm&r=g)
On Wed, Sep 11, 2019 at 5:05 AM Ned Batchelder <ned@nedbatchelder.com> wrote:
It always takes some time to go through the phases of a release. If the final release happened on Jan 1st, there wouldn't be time to get patches in during the tail of 2019. Python 2's sunset does indeed happen as 2020 starts, but before night completely falls, there are some final actions to be taken in order to produce one good, clean, final release. Plus the whole "let's align it with something else that's happening" thing, but that doesn't sound half as grand :) ChrisA
![](https://secure.gravatar.com/avatar/cd6aae9615c3b36130e2470902833a72.jpg?s=120&d=mm&r=g)
On Tue, Sep 10, 2019 at 10:03 PM Ned Batchelder <ned@nedbatchelder.com> wrote:
To me it seems pretty clear: On Jan 1st 2020, the 2.7.x branch will no longer receive fixes for any *new* bugs or security issues, nor other improvements. I would expect that be the time of the code freeze for the first release candidate, not the time of the final release. While we will still fix issues *introduced in 2.7.18 since 2.7.17* before the final 2.7.18 release, we won't address any other bugs or security issues and won't backport anything *new* from 3.x. (I may have some details not exactly correct here, but I hope the gist is correct.) I'm sure the wording could be improved, but generally this seems entirely reasonable to me. - Tal Einat
![](https://secure.gravatar.com/avatar/b2051833183f6ff9a789b01536b1b201.jpg?s=120&d=mm&r=g)
*RE: Ned's comments -- *That is the same reaction I had when I read through this thread. *RE: Tal's comment - *I could see this making sense as an explanation. *RE: Guido's comment* This makes me think that April 2020 is not a thing. And if Ben is supporting solo, then can people email him directly with issues? 😂😂😂 *On a serious note...* I would like clarification, so we (dev community and PSF) have a shared understanding of the direction and are sending the same messaging. -Jackie PSF Board of Directors On Tue, Sep 10, 2019 at 4:20 PM Tal Einat <taleinat@gmail.com> wrote:
-- Jacqueline Kazil | @jackiekazil
![](https://secure.gravatar.com/avatar/01aa7d6d4db83982a2f6dd363d0ee0f3.jpg?s=120&d=mm&r=g)
I think it’s fine to say that Python 2 EOL is on January 1, 2020. That doesn’t preclude a Contractual Obligation release in April. There’s precedence in the last Python 1 (1.6.1) release! https://en.wikipedia.org/wiki/Monty_Python%27s_Contractual_Obligation_Album -Barry
![](https://secure.gravatar.com/avatar/2828041405aa313004b6549acf918228.jpg?s=120&d=mm&r=g)
I think Ned's concerns are real, and the sunset-python-2 page could use some wordsmithing to explain that even though support ends on Jan 1, there will be a wrap-up release some time after that, but it won't incorporate any changes made or proposed after Jan 1. Another place where that document could be improved is in clarifying the different uses of the word "volunteers". For me, that's the most confusing part as I was reading it. As near as I can tell, these are different groups, or at least largely disjoint: * "We are volunteers who make and take care of the Python programming language" * "most volunteers will not help fix them" * "If you need free help from volunteers" Unfortunately I'm heading out of town and don't have time to help clean this up. Eric On 9/10/2019 5:09 PM, Jacqueline Kazil wrote:
![](https://secure.gravatar.com/avatar/342e4889fd14e21376a870e9d9ffc5d9.jpg?s=120&d=mm&r=g)
Hi. I've joined python-dev to participate in this thread (I don't have email delivery turned on; I'll be checking back via the web). Benjamin, I am sorry that I didn't check in with you, and assumed that January 1, 2020 would be the the date of the final 2.7 point release. (My understanding was based on Guido's EOL announcement from March last year https://mail.python.org/pipermail/python-dev/2018-March/152348.html -- I should have also gotten a review from you and not just the Steering Council in https://github.com/python/steering-council/issues/14 .) I'm going to continue this discussion here so I can make sure I understand the policy decision properly, and then (if necessary) update the FAQ. Based on what I've read here and what I see in https://www.python.org/dev/peps/pep-0373/#maintenance-releases , it sounds like the timeline will go something like: * 2019-10-19: release of 2.7.17 October * October, November, and December 2019: developers continue to fix issues in 2.7 * 2020-01-01: code freeze for 2.7.18 release candidate * January and February 2020: flexibility to fix any issues introduced since the 2.7.17 release, but no other bugs or security issues, and no 3.x backports * ~2020-04-02: release candidate for 2.7.18 * 2020-04-17: final 2.7.18 release Is this right? (If so, I can submit an update to PEP 373.) This is a little more complicated than I had anticipated when communicating out about the sunsetting. But I can find a way either to concisely communicate this, or to point to a user-friendly explanation elsewhere. Thanks. -- Sumana Harihareswara Changeset Consulting https://changeset.nyc
![](https://secure.gravatar.com/avatar/5dde29b54a3f1b76b2541d0a4a9b232c.jpg?s=120&d=mm&r=g)
Regardless of the date of the final release, no one's Python2 install will stop working, and people will still be able to download and install that last release. So I like the metaphor -- it's being "sunset" -- there will be a long dusk ...... a month or tow makes no difference to anyone's workflow. -CHB On Fri, Sep 13, 2019 at 6:39 PM Sumana Harihareswara <sh@changeset.nyc> wrote:
-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
![](https://secure.gravatar.com/avatar/cd2e442c42c95ed534e4197df4300222.jpg?s=120&d=mm&r=g)
On Fri, Sep 13, 2019, at 18:18, Sumana Harihareswara wrote:
Hi. I've joined python-dev to participate in this thread (I don't have email delivery turned on; I'll be checking back via the web).
sorry :)
Security issues will probably be fixed. At least, I wouldn't in abstract find that objectionable assuming someone wants to write a patch.
* ~2020-04-02: release candidate for 2.7.18 * 2020-04-17: final 2.7.18 release
I don't know if these will be the exact dates but probably close.
A succinct statement of the relevant information is: "After 10 years, the core developers of CPython are stopping development on the 2.7.x line. The last release will be in April 2020." If it's easier to communicate that the sunset of CPython 2 is April 2020, that seems fine with me. January 1 was a somewhat arbitrary date we put in the PEP when 2020 still seemed like a long way off but people wanted to know whether 2.7 would be released until 2021 or not. I was never going to make a 2.7 release literally on January 1. (Fighting with GPG would make short work of New Year's resolutions pertaining to temperance and strong language.) I failed to anticipate how strongly people would latch onto that exact moment in time as the end of Python 2. I additionally share the bemusement of some other commentators on this thread to the idea of Python 2 "support", which is not something ever promised to Python 2 (or 3) users by CPython core developers. Essentially, next year, we're changing our "support" policy of Python 2.7 from "none, but we're nice people" to "none".
![](https://secure.gravatar.com/avatar/880ac02012dcaf99f0392f69af4f8597.jpg?s=120&d=mm&r=g)
On 24/09/2019 04:21:45, Benjamin Peterson wrote:
I understand, but I hope that if a clear bug (perhaps especially a security bug) is found in Python 2.7 (perhaps one that is also in Python 3.x) the core devs will not be in principle opposed to fixing it. At least if one of them (or someone else sufficiently qualified) is prepared to do the work. Especially as you're "essentially" (and you ARE :-) -:) ) "such nice people". Best wishes Rob Cliffe
![](https://secure.gravatar.com/avatar/be200d614c47b5a4dbb6be867080e835.jpg?s=120&d=mm&r=g)
On 25Sep2019 2140, Benjamin Peterson wrote:
The biggest thing that will change is that all our CI systems will stop testing 2.7, and there's a good chance we'll lock (or delete?) the 2.7 branch from our repo. So you may find someone nice enough (or willing enough to accept money (or willing to accept enough money)) to fix an issue, but the fix will have to go somewhere other than the main repo and someone else will have to verify and release it. Cheers, Steve
![](https://secure.gravatar.com/avatar/addb93ccfcdb56a13a477192a7cf6a29.jpg?s=120&d=mm&r=g)
On Thu, Sep 26, 2019 at 1:58 PM Ethan Furman <ethan@stoneleaf.us> wrote:
Will there be a time delay between the final tagging and the deletion so any who would like the repo in its final state can clone it at that point?
No need; you can try this with any currently closed branch like 3.3: `git checkout -B 3.3 refs/tags/3.3` will check out a local `3.3` branch at the tag (resetting the `3.3` local branch if it already existed). The same will work for 2.7 after the branch is deleted.
![](https://secure.gravatar.com/avatar/d67ab5d94c2fed8ab6b727b62dc1b213.jpg?s=120&d=mm&r=g)
On Fri, Sep 27, 2019 at 5:04 AM Ethan Furman <ethan@stoneleaf.us> wrote:
If I've understood "tag" correctly, the commits should all remain in the repository for all time, so you should indeed be able to view it as of EOL. You can "git checkout v2.7.18" (or whatever the number is) after cloning the repository. ChrisA
![](https://secure.gravatar.com/avatar/5c3bcfa09d6365a980e775e65d2e0931.jpg?s=120&d=mm&r=g)
On Sep 26, 2019, at 14:50, Ethan Furman <ethan@stoneleaf.us> wrote:
Nothing will be lost, there's no need for a time delay. As we do for every release, there will be a tag created for the final 2.7 release of the form "v2.7.xx". That allows you to checkout the state of any release, including the final 2.7 release. At end-of-life time, we will also create a final "2.7" tag that reflects the final state of the 2.7, in case anything else was checked in following that last release. There will no longer be a "2.7" branch in the repo so it won't be possible to merge 2.7 changes back into the central repo. The 2.7 tag will act as sort of a read-only branch, i.e. you can still do: git checkout 2.7 to access it. If you want, you could create a local branch in your repo. See: https://devguide.python.org/devcycle/#end-of-life-branches -- Ned Deily nad@python.org -- []
![](https://secure.gravatar.com/avatar/342e4889fd14e21376a870e9d9ffc5d9.jpg?s=120&d=mm&r=g)
Per https://discuss.python.org/t/petition-abandon-plans-to-ship-a-2-7-18-in-apri... I have now: * written a PR to update PEP 373 to mark that the code freeze happened on 1 January https://github.com/python/peps/pull/1304 * updated the Python 3 Q&A http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_an... similarly https://bitbucket.org/ncoghlan/misc/pull-requests/21/update-python-3-q-a-to-... * added a "what happens now?" section to https://www.python.org/doc/sunset-python-2/ -- Sumana Harihareswara
![](https://secure.gravatar.com/avatar/342e4889fd14e21376a870e9d9ffc5d9.jpg?s=120&d=mm&r=g)
Benjamin: now that PyCon 2020 has been cancelled, are you considering releasing 2.7.18 slightly earlier? -- Sumana Harihareswara Changeset Consulting https://changeset.nyc
![](https://secure.gravatar.com/avatar/342e4889fd14e21376a870e9d9ffc5d9.jpg?s=120&d=mm&r=g)
On 3/27/20 12:49 PM, Sumana Harihareswara wrote:
Benjamin: now that PyCon 2020 has been cancelled, are you considering releasing 2.7.18 slightly earlier?
(I ask because: before you do that, I would like to submit some changes to the documentation for the 2.7 branch, to indicate to users that they ought to switch to Python 3.) Sumana Harihareswara Changeset Consulting https://changeset.nyc
![](https://secure.gravatar.com/avatar/342e4889fd14e21376a870e9d9ffc5d9.jpg?s=120&d=mm&r=g)
I'm sorry, I should have been more specific. I'm talking about the "switch to Python 3" banner that we need to add per discussion in https://github.com/python/steering-council/issues/3 . I am pretty sure it's not too late for that. -Sumana On 3/29/20 10:23 AM, Victor Stinner wrote:
![](https://secure.gravatar.com/avatar/342e4889fd14e21376a870e9d9ffc5d9.jpg?s=120&d=mm&r=g)
Thanks. I'm working to get https://github.com/python/steering-council/issues/3 resolved by April 17th to add an informational header to all the deep links within https://docs.python.org/2/* . I welcome help on the pull requests linked from that issue (such as https://github.com/python/cpython/pull/19229 ), and on the question Leonard Richardson asks there regarding https://github.com/python/devguide/blob/master/devcycle.rst .
![](https://secure.gravatar.com/avatar/342e4889fd14e21376a870e9d9ffc5d9.jpg?s=120&d=mm&r=g)
Benjamin or others: could you please review https://github.com/python/cpython/pull/19229 to "Add an optional obsolete header." to the 2.7 documentation today or tomorrow? Much thanks.
![](https://secure.gravatar.com/avatar/047f2332cde3730f1ed661eebb0c5686.jpg?s=120&d=mm&r=g)
It probably means that from January to April Benjamin will be too busy porting Dropbox to Python 3 to have time for Python 2 support. Or possibly it means that until PyCon 2020, there will be only one core developer supporting Python 2, and it will be Benjamin. You choose. :-) On Tue, Sep 10, 2019 at 4:00 PM Ned Batchelder <ned@nedbatchelder.com> wrote:
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
![](https://secure.gravatar.com/avatar/d6b9415353e04ffa6de5a8f3aaea0553.jpg?s=120&d=mm&r=g)
On 9/10/2019 10:54 AM, Ned Batchelder wrote:
What does the "official EOL date" mean if there's a release in April?
To me, it means that coredevs freely patching 2.7 ends 1/1/2020 and that the final release will occur by PyCon and that everything between the two is at the discretion of Benjamin, the release manager. I think that the first release candidate should be well before PyCon, maybe even in January, to make 2.7 EOL real and to allow time for a second or even a third, due to last minute pleas. But that is up to Benjamin. -- Terry Jan Reedy
![](https://secure.gravatar.com/avatar/e8600d16ba667cc8d7f00ddc9f254340.jpg?s=120&d=mm&r=g)
Stefan Behnel wrote:
It means we should all consider Python 2.7 EOL'ed come January 1 and Benjamin will make a release when it's convenient, and he just happens to know ahead of time that convenient for him is PyCon US 2020. :)
Also, what day in April? For example, planning the release for the 1st could possibly add further to the confusion.
PyCon US 2020 is mid-April, so if the release is going to coincide with the conference then it won't be at the beginning of the month.
![](https://secure.gravatar.com/avatar/c371bd9eebd30a2fa9a7253cb6be699d.jpg?s=120&d=mm&r=g)
Benjamin, what are you thoughts on usage of the "needs backport to 2.7" label? For most of the PRs I've reviewed I tend to avoid adding it myself, but I've seen it used periodically. It seems to be used rather infrequently ( https://github.com/python/cpython/pulls?q=is%3Apr+label%3A%22needs+backport+...), but I'm not entirely clear on when it should be used, particularly for documentation-related PRs. Also, is there an official date when the label will be removed? Removing the backport label seems to generally be at the discretion of the release manager for that version, but I was curious as to whether it would be removed on the sunset date or prior to then. Without the label, backport PRs can still be opened manually of course, but removing it would probably help to discourage 2.7 backports. On Mon, Sep 9, 2019 at 9:38 AM Benjamin Peterson <benjamin@python.org> wrote:
![](https://secure.gravatar.com/avatar/e8600d16ba667cc8d7f00ddc9f254340.jpg?s=120&d=mm&r=g)
Kyle Stanley wrote:
It should be used where appropriate. ;) It's a per-case thing where you have to balance backwards-compatibility with whatever you're changing. Plus you have to have someone doing the PR review who cares enough to deal with the (good) chance there will be a merge conflict in the backport.
![](https://secure.gravatar.com/avatar/cd2e442c42c95ed534e4197df4300222.jpg?s=120&d=mm&r=g)
On Wed, Sep 18, 2019, at 19:23, Kyle Stanley wrote:
I don't think the 2.7 backport label is currently overused. The 2.7 branch is already is a fairly quiet state. We've had less than 15 commits to 2.7 this month despite there being a week of more than 20 core developers intensely hacking on CPython. The label drives the automated backport tooling. There's no need to impede legitimate 2.7 backports.
účastníci (24)
-
Antoine Pitrou
-
Barry Warsaw
-
Benjamin Peterson
-
Brett Cannon
-
brian.skinn@gmail.com
-
Chris Angelico
-
Chris Barker
-
Eric V. Smith
-
Ethan Furman
-
Guido van Rossum
-
Jacqueline Kazil
-
Kyle Stanley
-
Ned Batchelder
-
Ned Deily
-
Rhodri James
-
Rob Cliffe
-
Stefan Behnel
-
Steve Dower
-
Steve Holden
-
Sumana Harihareswara
-
Tal Einat
-
Terry Reedy
-
Victor Stinner
-
Zachary Ware