PEP 605: Update for PEP 607 publication (#1212)

Also updates the NEP 29 section to cover the latest wording
of that proposal, and makes it clear that mere acceptance
of the PEP doesn't prevent us from ever changing the release
process again.

pep-0605.rst

@@ -9,24 +9,30 @@ Type: Informational
 Content-Type: text/x-rst
 Created: 20-Sep-2019
 Python-Version: 3.9
-Post-History: 1-Oct-2019, 6-Oct-2019
+Post-History: 1-Oct-2019, 6-Oct-2019, 20-Oct-2019
 
 
 Abstract
 ========
 
-Rather than proposing more frequent full CPython releases (as PEP 602 does),
-or a policy change to allow backwards compatible feature additions later in a
-release series (as PEP 598 does), this PEP instead proposes that we create a
-rolling stream of production-ready beta releases, together with alpha releases
-that are specifically designed to be suitable as platforms for building
-extension modules and wheel archives that are compatible with the subsequent
-beta releases.
+For a long time, CPython's nominal feature release cadence has been "every 18-24
+months", and in recent years, has been pretty consistently on the "18 month"
+end of that window. PEP 607 provides some common background on the problems
+that arise due to that choice of cadence, as well as some of the risks that
+need to be accounted for when proposing to change it.
 
-The key desired outcome of this proposal is that the usage guidance given for
-beta releases would become "suitable for production use only in environments
-with sufficiently robust compatibility testing and operational monitoring
-capabilities", rather than current unqualified "not for production use".
+The proposal in this PEP aims to allow CPython's user base to self-select into
+two distinct but overlapping groups:
+
+* users of stable feature releases (and their associated maintenance release
+  streams) that are published every 24 months; and
+* early adopters of a new rolling release stream that takes the place of the
+  previous CPython pre-release process
+
+As part of this proposal, the usage guidance given for beta releases would
+become "suitable for production use only in environments with sufficiently
+robust compatibility testing and operational monitoring capabilities", rather
+than the currently unqualified "not for production use".
 
 Similarly, the guidance given for alpha releases would be amended to state
 "intended for library compatibility testing and the creation of ABI compatible
@@ -39,7 +45,6 @@ This PEP also proposes that the frequency of X.Y.0 releases be adjusted to
 begin each new release series in August every two years (starting in 2021,
 around two years after the release of Python 3.8.0).
 
-
 Example Future Release Schedules
 ================================
 
@@ -380,6 +385,22 @@ feature delivery latency.
 Aims of this Proposal
 =====================
 
+The proposal in this PEP arises from making the following key assumptions:
+
+* the vast majority of Python's users aren't actively clamouring for new
+  language and runtime level features, and instead only upgrade when either
+  the version they were previously using is no longer supported, when their
+  Python provider switches to offering them a newer version by default, or when
+  enough changes that are of interest to them have accumulated to make a
+  compelling case for upgrading
+* for many users of new releases, much of the work that arises when adopting a
+  new release doesn't arise from compatibility issues at the language level, but
+  from compatibility issues at the component installation level (i.e. filename
+  and installation path changes)
+* that there's a subset of Python's user base that would be willing to run
+  production-ready pre-releases (akin to Windows Insider or Debian testing
+  builds) for at least some of their use cases
+
 The core of the proposal in this PEP is changing the CPython pre-release process
 to produce a rolling stream of incremental feature releases at a regular
 cadence, and to ensure that most of those builds offer a sufficient level of
@@ -773,6 +794,26 @@ However, for the sake of the example timelines, the PEP assumes maintenance
 releases every other month, allowing them to alternate months with the rolling
 pre-freeze releases.
 
+The release manager and Steering Council would also retain the power to amend
+various details of the proposal in this PEP. Possible amendments include (but
+are not limited to):
+
+* changing the timing for creation of the maintenance branch. If a major change
+  that would require a new alpha release is landed relatively late in the
+  pre-release process, the release manager could potentially choose to branch
+  off from a point prior to that major change. For example, it may make sense to
+  do this if the next scheduled release was intended to be the final beta
+  release or the first release candidate.
+* the criteria for declaring an alpha release could potentially be expanded to
+  include all changes that require a "Porting" entry in the What's New document
+* rather than declaring alpha releases on an as-needed basis, the release
+  manager could declare some dates as alpha releases in advance, and ask core
+  developers to time their higher risk changes accordingly.
+
+The intent of the concrete proposal in the PEP is to provide a clear
+illustrative example for reviewers to consider, not to constrain our ability
+to adjust specific details based on practical experience with the process.
+
 
 Design Discussion
 =================
@@ -854,8 +895,8 @@ be assigned to the *value* of any of the numbers in a release version. These
 community members instead prefer that all the semantic significance be
 associated with the *position* within the release number that is changing.
 
-By contrast, the rolling pre-freeze release proposal aims to address that concern by
-ensuring that the proposed changes in policy all revolve around whether a
+By contrast, the rolling pre-freeze release proposal aims to address that concern
+by ensuring that the proposed changes in policy all revolve around whether a
 particular release is an alpha release, beta release, release candidate, or
 final release.
 
@@ -1076,9 +1117,10 @@ Based on discussions at SciPy 2019, NEP (NumPy Enhancement Proposal) 29 has
 been drafted [3_] to propose a common convention across the Scientific Python
 ecosystem for dropping support for older Python versions.
 
-While the exact formulation of that policy is still being discussed, the initial
-proposal is very simple: support any Python feature release published within
-the last 42 months.
+While the exact formulation of that policy is still being discussed, the draft
+proposal (as of October 20, 2019) recommends that projects support any Python
+feature release published within the last 42 months, with a minimum of
+supporting the latest 2 Python feature releases.
 
 For an 18 month feature release cadence, that works out to always supporting at
 least the two most recent feature releases, and then dropping support for all
@@ -1089,15 +1131,15 @@ releases are supported.
 For a 12 month release cadence, it would work out to always supporting at
 least the three most recent feature releases, and then dropping support for all
 X.Y.Z releases around 6 months after X.(Y+3).0 is released. This means that
-for half of each year, the four most recent feature releases would be supported.
+for half of each year, the four most recent feature releases would be supported,
+with the other half of each year hopefully being used to get ready for that
+year's feature release.
 
-For a 24 month release cadence, a 42 month support cycle works out to always
-supporting at least the most recent feature release, and then dropping support
-for all X.Y.Z releases around 18 months after X.(Y+1).0 is released.
-This means there is a 6 month period every other year where only one feature
-release is supported. Under the proposal in this PEP, that period would
-correspond to the final few rolling pre-freeze releases and the release candidate
-phase for the upcoming stable feature release.
+For a 24 month release cadence, the second clause takes priority over the first,
+and the recommended Python version support period increases to 48 months from
+the initial X.Y.0 release in order to consistently support the two most recent
+CPython feature releases. For projects that also support the rolling release
+stream, the number of supported feature releases would increase to three.
 
 
 Release cycle alignment for core development sprints