Accepting PEP 602 -- Annual Release Cycle for Python
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!
On 30.10.19 20:26, Brett Cannon wrote:
This was discussed on https://discuss.python.org
I appreciate that you are informing the python-dev ML. However this discussion was never announced on the ML. I assume this is a kind of thing that makes the ML obsolete and forces everyone into discourse. Matthias
This PEP was mentioned on python-dev at least at https://mail.python.org/archives/list/python-dev@python.org/message/WQ64ZGBE... and https://mail.python.org/archives/list/python-dev@python.org/message/YVSOOFLC.... This was also covered by the PEP 596 discussion and https://mail.python.org/archives/list/python-dev@python.org/message/Y4XFD7OW... as PEP 602 was split out of PEP 596 and stated as such in that discussion since the latter PEP did double-duty initially as the 3.9 release schedule and changing the release cadence. I will also say that https://discuss.python.org/t/pep-602-annual-release-cycle-for-python/2296 received 84 replies from 22 participants and 83 replies from 13 people for PEP 605 at https://discuss.python.org/t/pep-605-a-rolling-feature-release-stream-for-cp... (the PEP 607 announcements never got replies anywhere from what I can tell) so there was participation by folks. When it comes to PEPs, people seem to have naturally gravitated to announcing PEPs on the appropriate mailing list and then directing people to dicsuss.python.org for discussion (specifically the https://discuss.python.org/c/peps category which is open to the public). If you consider that making MLs obsolete then I guess that's seems to have happened at least when it comes to general PEP discussion.
On Oct 30, 2019, at 12:50, Matthias Klose <doko@ubuntu.com> wrote:
On 30.10.19 20:26, Brett Cannon wrote:
This was discussed on https://discuss.python.org
I appreciate that you are informing the python-dev ML. However this discussion was never announced on the ML. I assume this is a kind of thing that makes the ML obsolete and forces everyone into discourse.
Doko, as to the substance of PEP 602, does the annual release cadence in October cause problems for Ubuntu? -Barry
On 30.10.19 22:22, Barry Warsaw wrote:
On Oct 30, 2019, at 12:50, Matthias Klose <doko@ubuntu.com> wrote:
On 30.10.19 20:26, Brett Cannon wrote:
This was discussed on https://discuss.python.org
I appreciate that you are informing the python-dev ML. However this discussion was never announced on the ML. I assume this is a kind of thing that makes the ML obsolete and forces everyone into discourse.
Doko, as to the substance of PEP 602, does the annual release cadence in October cause problems for Ubuntu?
It's around four months before the Ubuntu feature freeze [1], and six before the release in April (which every two years usually becomes a long term support release). Having a window of four months for the adoption, with new third party releases for 3.8/3.9 trickling in, might be a bit short. The adoption of 3.8 during this time frame might be more dominated by the removal of Python2 packages [2] (3300 sources affected, 1900 still to do). And having fun with third party packages without having 2.7 and 3.8 support in the same release, with the Py2 removal having a top to bottom order for dependencies, and the 3.8 addition a bottom to top order. We will see in 2021, how the distros will do with that work load and 3.9. An August or September release might help, but I think it's more the shortened release cycle which has a bigger effect. Matthias [1] https://wiki.ubuntu.com/FocalFossa/ReleaseSchedule [2] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=py2removal;users=debian-pyt...
On 30Oct2019 1226, Brett Cannon wrote:
* 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
I'm taking this as an indication that we should finish https://bugs.python.org/issue23903 to actually clean the stable ABI and make it usable on Windows. Specifically: * existing APIs that accidentally shipped in the stable ABI have to remain in the stable ABI if they are currently listed in python3.def * _all_ current stable ABI APIs according to the header files will be added to python3.def, whether they were intended to be stable or not (with a grace period of however long it takes us to finish issue23903) * in future, the file will be either auto-generated or validated against the actual headers, to ensure it doesn't get out of sync again Hopefully this won't be as upsetting to people as last time we tried to fix it, but if anyone still has concerns about the stable ABI not being properly clean, you need to speak up :) Also, PEP 602 makes no statement about when stable ABI APIs are "committed", and nor does PEP 384, so should we assume that the stable ABI becomes fixed at beta 1 (or RC 1)? That is, it is not allowed to remove or change any stable ABI APIs from beta/RC 1, even if they weren't in the previous release? Or will we hold it until the final release and allow breaking the stable ABI during prereleases. Cheers, Steve
Steve Dower wrote:
On 30Oct2019 1226, Brett Cannon wrote:
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
I'm taking this as an indication that we should finish
https://bugs.python.org/issue23903 to actually clean the stable ABI and make it usable on Windows.
I would, but then I would have wanted the stable ABI to be clean and work on Windows regardless. :)
Specifically:
existing APIs that accidentally shipped in the stable ABI have to remain in the stable ABI if they are currently listed in python3.def _all_ current stable ABI APIs according to the header files will be added to python3.def, whether they were intended to be stable or not (with a grace period of however long it takes us to finish issue23903) in future, the file will be either auto-generated or validated against the actual headers, to ensure it doesn't get out of sync again
Hopefully this won't be as upsetting to people as last time we tried to fix it, but if anyone still has concerns about the stable ABI not being properly clean, you need to speak up :) Also, PEP 602 makes no statement about when stable ABI APIs are "committed", and nor does PEP 384, so should we assume that the stable ABI becomes fixed at beta 1 (or RC 1)? That is, it is not allowed to remove or change any stable ABI APIs from beta/RC 1, even if they weren't in the previous release? Or will we hold it until the final release and allow breaking the stable ABI during prereleases.
Don't know. That's probably a discussion to have and decide where the results of that discusion should be specified (PEP 384, 387, or 602).
On Thu., 31 Oct. 2019, 6:14 am Steve Dower, <steve.dower@python.org> wrote:
Also, PEP 602 makes no statement about when stable ABI APIs are "committed", and nor does PEP 384, so should we assume that the stable ABI becomes fixed at beta 1 (or RC 1)? That is, it is not allowed to remove or change any stable ABI APIs from beta/RC 1, even if they weren't in the previous release? Or will we hold it until the final release and allow breaking the stable ABI during prereleases.
This is one of the still open questions. My current thinking is: * add the pre-freeze ABI flag proposed in PEP 605 * as long as that is set, both the full ABI and any stable ABI additions since the last stable release are still mutable * we emit a compile warning if the target stable ABI is set to the in-development pre-freeze one * clear the pre-freeze flag for rc1 That way folks will be able to freely build and publish binaries prior to rc1, as long as they're targeting the full ABI or an older version of the stable ABI. Cheers, Nick.
On 30 Oct 2019, at 20:26, Brett Cannon <brett@python.org> wrote:
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).
Thank you, I'm excited! Nit:
* 3 months for betas instead of 2
3 months instead of 4. But keep the number of releases, just compressing the timing between them slightly.
* 2 months for RCs instead of 1
Yes. This allows for synchronizing the schedule of Python release management with Fedora. They've been historically very helpful in early finding regressions not only in core Python but also in third-party libraries, helping moving the community forward. It seems like a bargain to make a slight adjustment of our schedule to help Fedora help us make 3.9 and beyond better releases. I'll make the necessary adjustments to PEP 602 first thing in the morning (hi from Poland!).
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 😉).
Looking forward to that! - Ł
On Oct 30, 2019, at 14:31, Łukasz Langa <lukasz@langa.pl> wrote:
Yes. This allows for synchronizing the schedule of Python release management with Fedora. They've been historically very helpful in early finding regressions not only in core Python but also in third-party libraries, helping moving the community forward. It seems like a bargain to make a slight adjustment of our schedule to help Fedora help us make 3.9 and beyond better releases.
It would be really interesting for the major distros to work together, coordinating their archive rebuilds with the new/beta releases. E.g. Ubuntu might be ahead of Fedora, or vice versa, for any particular new Python release. Rebuilding the whole archive with the new version as default always uncovered interesting issues. It seems like we have a great untapped resource to find good signals as to bugs, breakages, regressions, and other problems during the Python beta process. How can that be leveraged better? -Barry
Barry Warsaw wrote:
On Oct 30, 2019, at 14:31, Łukasz Langa lukasz@langa.pl wrote:
Yes. This allows for synchronizing the schedule of Python release management with Fedora. They've been historically very helpful in early finding regressions not only in core Python but also in third-party libraries, helping moving the community forward. It seems like a bargain to make a slight adjustment of our schedule to help Fedora help us make 3.9 and beyond better releases. It would be really interesting for the major distros to work together, coordinating their archive rebuilds with the new/beta releases. E.g. Ubuntu might be ahead of Fedora, or vice versa, for any particular new Python release. Rebuilding the whole archive with the new version as default always uncovered interesting issues. It seems like we have a great untapped resource to find good signals as to bugs, breakages, regressions, and other problems during the Python beta process. How can that be leveraged better?
I do ask that if there's going to be a discussion about distros working together and such that it be split off into its own thread to keep this one on-topic to be specific about the PEP's acceptance.
On Thu., 31 Oct. 2019, 8:30 am Brett Cannon, <brett@python.org> wrote:
On Oct 30, 2019, at 14:31, Łukasz Langa lukasz@langa.pl wrote:
Yes. This allows for synchronizing the schedule of Python release management with Fedora. They've been historically very helpful in early finding regressions not only in core Python but also in third-party
moving the community forward. It seems like a bargain to make a slight adjustment of our schedule to help Fedora help us make 3.9 and beyond better releases. It would be really interesting for the major distros to work together, coordinating their archive rebuilds with the new/beta releases. E.g. Ubuntu might be ahead of Fedora, or vice versa, for any particular new Python release. Rebuilding the whole archive with the new version as default always uncovered interesting issues. It seems like we have a great untapped resource to find good signals as to bugs, breakages, regressions, and other problems during the Python beta process. How can
Barry Warsaw wrote: libraries, helping that be leveraged
better?
I do ask that if there's going to be a discussion about distros working together and such that it be split off into its own thread to keep this one on-topic to be specific about the PEP's acceptance.
I think it also ties into the PEP 608 discussion of explicitly expanding our pre-release testing signals, so I'll take it up in that Discourse thread. Cheers, Nick.
On 10/30/19 4:20 PM, Barry Warsaw wrote:
On Oct 30, 2019, at 14:31, Łukasz Langa <lukasz@langa.pl> wrote:
Yes. This allows for synchronizing the schedule of Python release management with Fedora. They've been historically very helpful in early finding regressions not only in core Python but also in third-party libraries, helping moving the community forward. It seems like a bargain to make a slight adjustment of our schedule to help Fedora help us make 3.9 and beyond better releases.
It would be really interesting for the major distros to work together, coordinating their archive rebuilds with the new/beta releases. E.g. Ubuntu might be ahead of Fedora, or vice versa, for any particular new Python release. Rebuilding the whole archive with the new version as default always uncovered interesting issues. It seems like we have a great untapped resource to find good signals as to bugs, breakages, regressions, and other problems during the Python beta process. How can that be leveraged better?
Just slightly off topic (sorry Brett), but I have past experience with the effort to try and sync the release cycle of something significant with that of major distros - and it's just too hard. (What are major "the major distros" anyway? the enterprise ones are on a completely different cycle, and some have gone to rolling releases where there's really nothing to sync to). By all means, if it hurts nothing to go for a sync now, to take advantage of some synergies, great, but don't try enshrine it in a PEP as a requirement going forward, there will only be lots of pain as things start to skew. And they will.
On Fri., 1 Nov. 2019, 4:15 am Mats Wichmann, <mats@wichmann.us> wrote:
Just slightly off topic (sorry Brett), but I have past experience with the effort to try and sync the release cycle of something significant with that of major distros - and it's just too hard. (What are major "the major distros" anyway? the enterprise ones are on a completely different cycle, and some have gone to rolling releases where there's really nothing to sync to). By all means, if it hurts nothing to go for a sync now, to take advantage of some synergies, great, but don't try enshrine it in a PEP as a requirement going forward, there will only be lots of pain as things start to skew. And they will.
This was actually one of the benefits of PEP 602: while Ubuntu LTS and Debian being offset means that every Python version is likely to find its way into one long lived Linux distro or another, the 12 month cadence means that when cycles don't line up well enough for immediate adoption, even the previous version should still be less than 18 months old (e.g. if Debian 11 were to ship Python 3.8 early in 2021 instead of 3.9). The balance between alpha/beta/rc is definitely negotiable though, and I expect we'll see iteration on that aspect over the first few years. Cheers, Nick.
Did you weigh PEP 602 against PEP 605? Is there a summary of the strong points you found for each and how you decided for the former? Thank you Antoine. On Wed, 30 Oct 2019 19:26:35 -0000 "Brett Cannon" <brett@python.org> wrote:
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-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/KE7OS4PZ... Code of Conduct: http://python.org/psf/codeofconduct/
On Sat., 2 Nov. 2019, 7:05 am Antoine Pitrou, <solipsis@pitrou.net> wrote:
Did you weigh PEP 602 against PEP 605? Is there a summary of the strong points you found for each and how you decided for the former?
The summary in PEP 607 was accepted as making a convincing case against the status quo. For the comparison between the PEPs, the main problem with PEP 605 was the base 24 month release cycle, as that causes a whole lot of release cycle synchronization problems (a redistributor missing the release train means shipping something 24-30 months old, rather than PEP 602's 12-18 months, or the status quo's 18-24 months), and also increases the temptation to push features into a release before they're ready. The 24 month cycle was also what drove the ABI management complexity in PEP 605's rolling release stream proposal, whereas the 12 month cycle can more readily stick with the familiar alpha/beta/rc sequence. For the points beyond that, there were going to need to be adjustments either way (e.g. many of the issues to be addressed in making annual releases easier for libraries and applications to support are similar to those that would have been needed to make the rolling release stream feasible to support). Cheers, Nick.
Thank you
Antoine.
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
* 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
On Wed, 30 Oct 2019 19:26:35 -0000 "Brett Cannon" <brett@python.org> wrote: projects for the final release 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-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/KE7OS4PZ... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ 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/B2OZTVNI... Code of Conduct: http://python.org/psf/codeofconduct/
участники (8)
-
Antoine Pitrou -
Barry Warsaw -
Brett Cannon -
Mats Wichmann -
Matthias Klose -
Nick Coghlan -
Steve Dower -
Łukasz Langa