On behalf of the steering council I am happy to announce that as BDFL-Delegate 
I am accepting PEP 602 to move us to an annual release schedule (gated on a 
planned update; see below).

The steering council thinks that having a consistent schedule every year when 
we hit beta, RC, and final it will help the community:

* Know when to start testing the beta to provide feedback
* Known when the expect the RC so the community can prepare their projects for 
the final release
* Know when the final release will occur to coordinate their own releases (if 
necessary) when the final release of Python occurs
* Allow core developers to more easily plan their work to make sure work lands 
in the release they are targeting
* Make sure that core developers and the community have a shorter amount of 
time to wait for new features to be released

The acceptance is gated on Łukasz updating PEP 602 to reflect a planned shift 
in scheduling (he's been busy with a release of Black):

* 3 months for betas instead of 2
* 2 months for RCs instead of 1

This was discussed on https://discuss.python.org in order to give the community 
enough time to provide feedback in the betas while having enough time to 
thoroughly test the RC and to prep for the final release so the delay from 
Python's final release to any new project releases is minimal. It should also 
fit into the release schedule of Linux distributions like Fedora better than 
previously proposed so the distributions can test the RC when they start 
preparing for their own October releases. If this turns out to be a mistake 
after we try it out for Python 3.9 we can then discuss going back to longer 
betas and shorter RCs for the release after that. This will not change when 
feature development is cut off relative to PyCon US nor the core dev sprints 
happening just before the final release or the alpha of the next version.

To help people who cannot upgrade on an annual cycle, do note that:

* PEP 602 now says that deprecations will last two releases which is two years 
instead of the current 18 months
* Now that the stable ABI has been cleaned, extension modules should feel more 
comfortable targeting the stable ABI which should make supporting newer 
versions of Python much easier

As part of the shift to a 2 year deprecation time frame I will be restarting 
discussions around PEP 387 as BDFL-Delegate so we can have a more clear 
deprecation and backwards-compatibility policy as well for those that find an 
annual cycle too fast which will be updated to reflect this two year time frame 
(head's up, Benjamin 😉).

Thanks to Łukasz, Nick, and Steve for PEPs 602, 605, and 607 and everyone else 
who provided feedback on those PEPs!
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
Message archived at 
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to