[ACCEPTED] PEP 602: Annual Release Cycle for Python

PEPs
81

That would probably work for Fedora. But it also makes the beta period shorter by one release. I don’t think that’s wise, but it might work, as the expected amount of changes is lower with the shorter release cycle.

82

I’m thinking maybe we could eat the cake and have it too by compressing the betas a bit and releasing one every 21 days instead of one every 28 days. After four releases we’d save four weeks et voila.

3 Likes
83

Then pick your poison: longer beta or longer RC?

84

From the distributor point of view? Definitively RC. I’ve just assumed that from the core dev PoV it might be Betas.

1 Like
85

This would work nicely.

1 Like
86

In the past, when the releases only slightly misaligned, Ubuntu would ship a late beta or rc in the final release and then update it to the final release in a subsequent point-release of Ubuntu. Not ideal, but given that all distros will have to synchronize with Python point releases anyway, is that too onerous?

87

That would be a thing to plan as a contingency plan if Python slips. I was just trying to avoid this being the default.

1 Like
88

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
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
6 Likes