@mauve It’s a frustrating situation, I’m partly at fault since my team has been running communications on this, and I’m sorry you’re running into it. I do think the situation is fundamentally confusing and counter to most people’s expectations regarding what “sunset/EOL” and “support” mean. And I am in favor of your idea of freezing a 2.7.18 release candidate now to make our commitment to the January 1st sunset as concrete as possible (while respecting @benjamin’s prerogative regarding the 2.7.18 release date).
Here’s how the Python 2.7.18 situation works, as I understand it:
Python 2.7.18 is planned for release during PyCon North America in April 2020, per PEP 373 . More details:
January 1, 2020: Code freeze for Python 2.7.18
The “End of Life/sunset” of Python 2.7 will be January 1, 2020. Until January 1, 2020, the release manager for 2.7.x will be working on Release 2.7.18, the final release of Python. On January 1, 2020, the release manager will stop development and freeze the codebase (see python-dev discussion): from that date, there will be no backports to 2.7.18 from Python 3.
April 2020: Final Production Release of Python 2.7.18
It is expected that there will be no patches after the code freeze date for 2.7.18. (We do not expect any regressions to be introduced between the Python 2.7.17 release in October 2019 and the code freeze date of January 1, 2020.) Between January 1, 2020 and April 2020, the release manager will shepherd the release through the beta and Release Candidate process.
(I based this on discussions with core developers, such as this python-dev thread.)
As my team works to update multiple documents about the sunset, I’d like to know: were there any regressions introduced between the Python 2.7.17 release and the code freeze on 1 January?