The Python 2 death march
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
It says it's feeling fine ;-) Regards Antoine. On Mon, 09 Sep 2019 14:29:51 +0100 "Benjamin Peterson" <benjamin@python.org> wrote:
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
It's not dead, it's just restin' after a particularly heavy release process. regards Steve Holden On Mon, Sep 9, 2019 at 4:24 PM Rhodri James <rhodri@kynesim.co.uk> wrote:
On 09/09/2019 15:51, brian.skinn@gmail.com wrote:
.... it's getting better?
No it's not, it'll be stone dead in a moment.
-- Rhodri James *-* Kynesim Ltd _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/AUMYGJ44...
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:
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 _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/APWHFYQD...
On Tue, Sep 10, 2019, at 15:54, Ned Batchelder wrote:
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?
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.
On 9/10/19 11:06 AM, Benjamin Peterson wrote:
On Tue, Sep 10, 2019, at 15:54, Ned Batchelder wrote:
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? 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.
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.
On Wed, Sep 11, 2019 at 5:05 AM Ned Batchelder <ned@nedbatchelder.com> wrote:
On 9/10/19 11:06 AM, Benjamin Peterson wrote:
On Tue, Sep 10, 2019, at 15:54, Ned Batchelder wrote:
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? 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.
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..
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
On Tue, Sep 10, 2019 at 10:03 PM Ned Batchelder <ned@nedbatchelder.com> 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..
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
*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:
On Tue, Sep 10, 2019 at 10:03 PM Ned Batchelder <ned@nedbatchelder.com> 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..
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 _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KSU2A5SD...
-- Jacqueline Kazil | @jackiekazil
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
On Sep 10, 2019, at 14:09, Jacqueline Kazil <jackiekazil@gmail.com> wrote:
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: On Tue, Sep 10, 2019 at 10:03 PM Ned Batchelder <ned@nedbatchelder.com> 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..
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 _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KSU2A5SD...
-- Jacqueline Kazil | @jackiekazil
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WOAYYHGI...
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:
*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 <mailto:taleinat@gmail.com>> wrote:
On Tue, Sep 10, 2019 at 10:03 PM Ned Batchelder <ned@nedbatchelder.com <mailto:ned@nedbatchelder.com>> 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..
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 _______________________________________________ Python-Dev mailing list -- python-dev@python.org <mailto:python-dev@python.org> To unsubscribe send an email to python-dev-leave@python.org <mailto:python-dev-leave@python.org> https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KSU2A5SD...
-- Jacqueline Kazil | @jackiekazil
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WOAYYHGI...
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
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:
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 _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MXCGMTXD...
-- 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
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 :)
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
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.
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.
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".
Thanks.
-- Sumana Harihareswara Changeset Consulting https://changeset.nyc _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MXCGMTXD...
On 24/09/2019 04:21:45, Benjamin Peterson wrote:
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 :)
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 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.
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. 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".
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
Thanks.
-- Sumana Harihareswara Changeset Consulting https://changeset.nyc _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MXCGMTXD...
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ETOBPFVK...
--- This email has been checked for viruses by AVG. https://www.avg.com
On Wed, Sep 25, 2019, at 17:25, Rob Cliffe via Python-Dev wrote:
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". 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".
Before 2.7.18, sure. After that, in principle and practice, we're opposed.
On 25Sep2019 2140, Benjamin Peterson wrote:
On Wed, Sep 25, 2019, at 17:25, Rob Cliffe via Python-Dev wrote:
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". 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".
Before 2.7.18, sure. After that, in principle and practice, we're opposed.
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
Steve Dower wrote:
On 25Sep2019 2140, Benjamin Peterson wrote:
On Wed, Sep 25, 2019, at 17:25, Rob Cliffe via Python-Dev wrote: 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". 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". Before 2.7.18, sure. After that, in principle and practice, we're opposed. 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.
A final tag of the branch will be made and then the branch will be deleted (it's how we handle all EOL versions). -Brett
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
On 09/26/2019 09:28 AM, Brett Cannon wrote:
Steve Dower 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.
A final tag of the branch will be made and then the branch will be deleted (it's how we handle all EOL versions).
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? -- ~Ethan~
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.
On Fri, Sep 27, 2019 at 5:04 AM Ethan Furman <ethan@stoneleaf.us> wrote:
On 09/26/2019 09:28 AM, Brett Cannon wrote:
Steve Dower 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.
A final tag of the branch will be made and then the branch will be deleted (it's how we handle all EOL versions).
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?
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
On Sep 26, 2019, at 14:50, Ethan Furman <ethan@stoneleaf.us> wrote:
On 09/26/2019 09:28 AM, Brett Cannon wrote:
Steve Dower 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. A final tag of the branch will be made and then the branch will be deleted (it's how we handle all EOL versions).
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?
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 -- []
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
Benjamin: now that PyCon 2020 has been cancelled, are you considering releasing 2.7.18 slightly earlier? -- Sumana Harihareswara Changeset Consulting https://changeset.nyc
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
IMHO it's too late to touch the Python 2.7 documentation. Victor Le dim. 29 mars 2020 à 16:01, Sumana Harihareswara <sh@changeset.nyc> a écrit :
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 _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/BH34OE3T... Code of Conduct: http://python.org/psf/codeofconduct/
-- Night gathers, and now my watch begins. It shall not end until my death.
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:
IMHO it's too late to touch the Python 2.7 documentation.
Victor
Le dim. 29 mars 2020 à 16:01, Sumana Harihareswara <sh@changeset.nyc> a écrit :
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.)
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 .
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.
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:
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.
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
On 9/9/19 9:29 AM, Benjamin Peterson wrote: 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 _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/APWHFYQD... _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TVIMZGRZ...
-- --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...>
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
Stefan Behnel wrote:
Ned Batchelder schrieb am 10.09.19 um 16:54:
this seems confusing to me What does the "official EOL date" mean if there's a release in April?
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.
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:
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 _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/APWHFYQD...
Kyle Stanley wrote:
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.
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.
On Wed, Sep 18, 2019, at 19:23, Kyle Stanley wrote:
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.
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.
participants (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