Final update
As requested by @brettcannon on python-dev and discussed with @hroncok here, I submitted a final update to the PEP. Commit: 493dc56.
I don’t have time now to update the PEP body in the original post here but here’s the diff:
diff --git a/pep-0602.rst b/pep-0602.rst
index 268996ca..efb3c43d 100644
--- a/pep-0602.rst
+++ b/pep-0602.rst
@@ -36,15 +36,16 @@ This PEP proposes that Python 3.X.0 will be developed for around
- The next *seven months* are spent on versioned alpha releases where
both new features are incrementally added and bug fixes are included.
-- The following *four months* are spent on versioned beta releases where
- **no new features** can be added but bug fixes are still included.
+- The following *three months* are spent on four versioned beta releases
+ where **no new features** can be added but bug fixes are still
+ included.
-- The *final month* is spent on a release candidate (or more, if
- necessary) and concludes with the release of the final release of
+- The final *two months* are spent on two release candidates (or more,
+ if necessary) and conclude with the release of the final release of
Python 3.X.0.
-One year of full support, four more years of security fixes
------------------------------------------------------------
+1½ year of full support, 3½ more years of security fixes
+--------------------------------------------------------
After the release of Python 3.X.0, the 3.X series is maintained for
five years:
@@ -81,11 +82,11 @@ Example
- 3.9.0 beta 1: Monday, 2020-05-18
(No new features beyond this point.)
-- 3.9.0 beta 2: Monday, 2020-06-15
-- 3.9.0 beta 3: Monday, 2020-07-13
-- 3.9.0 beta 4: Monday, 2020-08-17
-- 3.9.0 candidate 1: Monday, 2020-09-14
-- 3.9.0 candidate 2: Monday, 2020-09-21 (if necessary)
+- 3.9.0 beta 2: Monday, 2020-06-08
+- 3.9.0 beta 3: Monday, 2020-06-29
+- 3.9.0 beta 4: Monday, 2020-07-20
+- 3.9.0 candidate 1: Monday, 2020-08-10
+- 3.9.0 candidate 2: Monday, 2020-09-14
- 3.9.0 final: Monday, 2020-10-05
.. figure:: pep-0602-example-release-calendar.png
@@ -168,6 +169,12 @@ This change provides the following advantages:
- decreases the urge to rush features shortly before "Beta 1" due to
the risk of them "slipping for 18 months";
+- allows for synchronizing the schedule of Python release management
+ with external distributors like Fedora who've been historically very
+ helpful in finding regressions early not only in core Python but also
+ in third-party libraries, helping moving the community forward to
+ support the latest version of Python from Day 1;
+
- increases the explicit alpha release phase, which provides meaningful
snapshots of progress on new features;
@@ -285,8 +292,21 @@ Double the release cadence to achieve 9 months between major versions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This was originally proposed in PEP 596 and rejected as both too
-irregular and too short. One consequence of a 9 month release cadence
-was shortening of the beta phase and this was considered dangerous.
+irregular and too short. This would not give any of the benefits of
+a regular release calendar but it would shorten all development phases,
+especially the beta + RC phases. This was considered dangerous.
+
+Keep "4 betas over 4 months and a final month for the release candidate"
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+While this would make the release calendar a bit cleaner, `it would make
+it very hard for external distributors like Fedora
+<https://discuss.python.org/t/pep-602-annual-release-cycle-for-python/2296/79?u=ambv>`_
+to release the newest version of Python as soon as possible. We are
+adjusting Python's calendar here in the hope that this will enable
+Fedora to integrate the newest version of Python with the newest version
+of Fedora *as both are being developed* which makes both projects
+better.
Slow down releases but don't freeze feature development with Beta 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~