[pep-602] Increase full bugfix support to 18 months based on feedback

pep-0602.rst

@@ -48,13 +48,13 @@ One year of full support, four more years of security fixes
 After the release of Python 3.X.0, the 3.X series is maintained for
 five years:
 
-- During the *first year* it receives bugfix updates approximately
+- During the *first eighteen months* (1½ year) it receives bugfix
-  every month.  After the release of 3.(X+1).0 final, a final 3.X.12 is
+  updates and full releases (sources and installers for Windows and
-  released.
+  macOS) are made approximately every other month.
 
-- For the next *four years* it receives security updates and
+- For the next *forty two months* (3½ years) it receives security
-  source-only releases are made on an as-needed basis
+  updates and source-only releases are made on an as-needed basis
-  (no monthly cadence).
+  (no fixed cadence).
 
 - The final source-only release is made *five years* after 3.X.0.
 
@@ -93,6 +93,23 @@ Example
 
    Figure 1. Consequences of the annual release cycle on the calendar.
 
+In comparison, if this PEP is rejected and Python keeps the current
+release schedule:
+
+- 3.9 development begins: Tuesday, 2019-06-04
+- 3.9.0 alpha 1: Monday, 2020-08-03  (10 months later)
+- 3.9.0 alpha 2: Monday, 2020-09-07
+- 3.9.0 alpha 3: Monday, 2020-10-05
+- 3.9.0 alpha 4: Monday, 2020-11-02
+- 3.9.0 beta 1: Monday, 2020-11-30  (6 months later)
+- 3.9.0 beta 2: Monday, 2021-01-04
+- 3.9.0 beta 3: Monday, 2021-02-01
+- 3.9.0 beta 4: Monday, 2021-03-01
+- 3.9.0 candidate 1: Monday, 2021-03-29
+- 3.9.0 candidate 2: Monday, 2021-04-05 (if necessary)
+- 3.9.0 final: Monday, 2021-04-19  (6 months later)
+
+
 
 Rationale and Goals
 ===================
@@ -141,8 +158,9 @@ a separate PEP.
 Non-risks
 ---------
 
-This change does not shorten the security updates calendar for a Python
+This change does not shorten the currently documented support calendar
-release.
+for a Python release, both in terms of bugfix releases and security
+fixes.
 
 This change does not accelerate the velocity of development.  Python is
 not going to become incompatible faster or accrue new features faster.
@@ -152,24 +170,42 @@ are developed.
 Consequently, while this change introduces the ability for users to
 upgrade much faster, it does not require them to do so.  Say, if they
 upgrade every second release, their experience with Python is going to
-be very similar to the current situation.
+be similar to the current situation.
 
 Risks
 -----
 
+Python redistribution
+~~~~~~~~~~~~~~~~~~~~~
+
 This requires changes to how integrators, like Linux distributions,
 release Python within their systems.
 
+The testing matrix
+~~~~~~~~~~~~~~~~~~
+
 This eventually increases the testing matrix for library and application
 maintainers that want to support all actively supported Python versions
 by one or two:
 
 .. figure:: pep-0602-overlapping-support-matrix.png
    :align: center
-   :width: 100%
+   :width: 50%
 
    Figure 2. Testing matrix in the 18-month cadence vs. the 12-month
 
+The "extended bugfix support at the discretion of the Release Manager"
+stage of the current release cycle is not codified.  If fact, PEP 101
+currently states that after the release of Python 3.(X+1).0 only one
+last bugfix release is made for Python 3.X.0.  However, in practice at
+least the last four versions of Python 3 overlapped with stable releases
+of the next version for around six months.  Figure 2 is including
+this information to demonstrate that overlap between stable version
+releases with the 12-month release cadence will be nothing new.
+
+Some policies depend on the release cadence
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
 The following policies depend on the release cadence and will have to
 be updated:
 
@@ -178,12 +214,6 @@ be updated:
 - the term of the Steering Council
 - the term of the Release Manager
 
-Finally, this shortens the bugfix period to twelve months.  This allows
-core developers to increase the cadence without increasing the biggest
-maintenance cost, however provides an inconvenience to the user.  This
-particular risk might be solved by making every n-th release a LTS, in
-the vein of Python 2.7.  This is open for debate.
-
 Rejected Ideas
 --------------
 
@@ -193,6 +223,9 @@ Keep the current 18 month release cadence
 This is undesirable both for core developers and end users. From the
 perspective of the core developer:
 
+- it makes contribution scheduling harder due to irregular release
+  dates every year;
+
 - it creates a surge of rushed commits before (and even after!) Beta 1
   due to the stress involved with "missing a release";
 
@@ -233,6 +266,16 @@ to understand.  The presented advantages are unclear while the
 unfamiliarity of the scheme poses a real risk of user and integrator
 confusion.
 
+Long-Term Support Releases
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Each version of Python is effectively long-term support: it's supported
+for five years, with the first eighteen months allowing regular bug
+fixes and security updates.  For the remaining time security updates are
+accepted and promptly released.
+
+No extended support in the vein of Python 2.7 is planned going forward.
+
 
 Copyright
 =========