PEP 598: Adjust terminology and other updates (#1109)

- use baseline feature release and incremental feature release rather than major/minor feature release - introduce a new "feature_complete" flag on sys.version_info to allow the branch state to be inspected at runtime - impose a runtime feature detection requirement on all features added in incremental feature releases
2019-06-19 23:17:36 +10:00 · 2019-06-19 23:17:36 +10:00 · a721d2c854
parent efc5a1d88f
commit a721d2c854
1 changed files with 184 additions and 121 deletions
--- a/pep-0598.rst
+++ b/pep-0598.rst
@ -1,5 +1,5 @@
 PEP: 598
-Title: Introducing minor feature releases
+Title: Introducing incremental feature releases
 Version: $Revision$
 Last-Modified: $Date$
 Author: Nick Coghlan <ncoghlan@gmail.com>
@ -31,10 +31,16 @@ releases.
 This PEP presents a competing proposal to instead *slow down* the frequency of
 parallel installable major feature releases that change the filesystem layout
 and CPython ABI to a consistent 24 month cycle, but to compensate for this by
-introducing the notion of build compatible minor feature releases, and then
+introducing the notion of build compatible incremental feature releases, and
-deferring the full feature freeze of a given major release series from the
+then deferring the full feature freeze of a given major release series from the
-initial X.Y.0 release to an X.Y.Z minor feature release that occurs ~12 months
+initial baseline X.Y.0 release to a subsequent X.Y.Z feature complete release
-after that initial release.
+that occurs ~12 months after the initial baseline feature release.
 A new ``feature_complete`` attribute on the ``sys.version_info`` structure will
 provide a programmatic indicator as to whether or not a release series remains
 open to further incremental feature releases. Alternate implementations of
 Python would also be free to clear this flag to indicate that their support for
 their nominal Python version may still be a work in progress.
 The existing cycle and the new cycle would be synchronised on their feature
 freeze release dates, so the full Python 3.9.x feature freeze would occur in
@ -61,11 +67,11 @@ release timeline would look like:
 * 2020-08: 3.9.0bX (final beta release that locks ABI compatibility)
 * 2020-09: 3.9.0rc1
 * ... additional release candidates as determined by the release manager
-* 2020-10: 3.9.0
+* 2020-10: 3.9.0 (BFR - baseline feature release)
-* 2021-01: 3.9.1
+* 2021-01: 3.9.1 (IFR - incremental feature release)
-* 2021-04: 3.9.2
+* 2021-04: 3.9.2 (IFR)
-* 2021-07: 3.9.3
+* 2021-07: 3.9.3 (IFR)
-* 2021-10: 3.9.4 (final minor feature release)
+* 2021-10: 3.9.4 (feature complete release)
 * 2022-01: 3.9.5
 * 2022-04: 3.9.6
 * 2022-07: 3.9.7
@ -73,8 +79,13 @@ release timeline would look like:
 * ... additional security fix only releases as needed
 * 2025-10: 3.9.x branch closed
 Feature complete release numbers would typically be written without any
 qualifier (as they are today), while the baseline and incremental feature
 releases would be expected to have a qualifier appended indicating that they
 aren't a traditional CPython release (``3.9.0 (BFR)``, ``3.9.1 (IFR)``, etc).
 The Python 3.10 release series would start being published the month after the
-final Python 3.9 minor feature release, in parallel with the final 12 months
+first Python 3.9 feature complete release, in parallel with the final 12 months
 of routine Python 3.9 maintenance releases:
 * 2021-11: 3.10.0a1
@ -84,11 +95,11 @@ of routine Python 3.9 maintenance releases:
 * 2022-08: 3.10.0bX (final beta release that locks ABI compatibility)
 * 2022-09: 3.10.0rc1
 * ... additional release candidates as determined by the release manager
-* 2022-10: 3.10.0
+* 2022-10: 3.10.0 (BFR)
-* 2023-01: 3.10.1
+* 2023-01: 3.10.1 (IFR)
-* 2023-04: 3.10.2
+* 2023-04: 3.10.2 (IFR)
-* 2023-07: 3.10.3
+* 2023-07: 3.10.3 (IFR)
-* 2023-10: 3.10.4 (final minor feature release)
+* 2023-10: 3.10.4
 * 2024-01: 3.10.5
 * 2024-04: 3.10.6
 * 2024-07: 3.10.7
@ -101,10 +112,10 @@ In this model, there are always two or three active branches:
 * 2019-04 -> 2019-10: 3.9.0 pre-alpha, 3.8.0 pre-release, 3.7.x maintenance
 * 2019-10 -> 2020-05: 3.9.0 pre-beta, 3.8.x maintenance
 * 2020-05 -> 2020-10: 3.10.0 pre-alpha, 3.9.0 pre-release, 3.8.x maintenance
-* 2020-10 -> 2021-10: 3.10.0 pre-alpha, 3.9.x feature addition, 3.8.x maintenance
+* 2020-10 -> 2021-10: 3.10.0 pre-alpha, 3.9.x feature releases, 3.8.x maintenance
 * 2021-10 -> 2022-05: 3.10.0 pre-beta, 3.9.x maintenance
 * 2022-05 -> 2022-10: 3.11.0 pre-alpha, 3.10.0 pre-release, 3.9.x maintenance
-* 2022-10 -> 2023-10: 3.11.0 pre-alpha, 3.10.x feature addition, 3.9.x maintenance
+* 2022-10 -> 2023-10: 3.11.0 pre-alpha, 3.10.x feature releases, 3.9.x maintenance
 * 2023-10 -> 2024-05: 3.11.0 pre-beta, 3.10.x maintenance
 * 2024-05 -> 2024-10: 3.12.0 pre-alpha, 3.11.0 pre-release, 3.10.x maintenance
 * ... etc
@ -118,11 +129,11 @@ once I have one to add.
 This is quite similar to the status quo, but with a more consistent cadence,
 alternating between major feature release years (2020, 2022, etc) that focus
-on the alpha and beta cycle for a new major feature release (while continuing
+on the alpha and beta cycle for a new baseline feature release (while continuing
 to publish maintenance releases for the previous major release series), and
-minor feature release years (2021, 2023, etc), that focus on making smaller
+incremental feature release years (2021, 2023, etc), that focus on making
-improvements to the current major release series (while making plans for the
+smaller improvements to the current major release series (while making plans
-next major release the following year).
+for the next major release series the following year).
 Proposal
@ -131,11 +142,11 @@ Proposal
 Excluding alpha and beta releases, CPython currently has 3 different kinds
 of release increment:
-* Feature release (i.e. ``X.Y.0`` releases)
+* Feature release (i.e. X.Y.0 releases)
-* Maintenance release (``X.Y.Z`` releases within ~2 years of ``X.Y.0``)
+* Maintenance release (X.Y.Z releases within ~2 years of X.Y.0)
-* Source-only security release (subsequent ``X.Y.Z`` releases)
+* Source-only security release (subsequent X.Y.Z releases)
-Feature freeze takes place at the time of the ``X.Y.0b1`` release.
+Feature freeze takes place at the time of the X.Y.0b1 release.
 Build compatibility freeze now takes place at the time of the last beta release
 (providing time for projects to upload wheel archives to PyPI prior to the
 first release candidate).
@ -149,43 +160,44 @@ This then creates the following periods in the lifecycle of a release series:
 * End of life (no further releases of any kind)
 The proposal in this PEP is that the "Feature release" category be split up into
-two different kinds of feature release:
+three different kinds of feature release:
-* Major feature release (``X.Y.0`` releases)
+* Baseline feature release (X.Y.0 releases)
-* Minor feature release (``X.Y.Z`` releases within ~1 year of ``X.Y.0``)
+* Incremental feature release (any X.Y.Z releases published between a
-* Maintenance release (``X.Y.Z`` releases within ~1-2 years of  of ``X.Y.0``)
+  baseline feature release and the corresponding feature complete release)
 * Feature complete release (a specific X.Y.Z release ~1 year after X.Y.0)
 * Maintenance release (X.Y.Z releases within ~1 years of the feature complete release)
 * Source-only security release (subsequent ``X.Y.Z`` releases)
-This would then introduce a new "Feature additions" phase in the release series
+This would then introduce a new "Feature releases" phase in the release series
 lifecycle:
 * Pre-beta (release series is the CPython development branch)
 * Beta (release enters feature additions mode, ABI compatibility not yet locked)
-* Feature additions (ABI locked, API additions accepted)
+* Feature releases (ABI locked, backwards compatible API additions accepted)
-* Maintenance only (ABI locked, only bug fixes & docs enhancements accepted)
+* Maintenance (ABI locked, only bug fixes & docs enhancements accepted)
 * Security fix only (no further binary releases, only security fixes accepted)
 * End of life (no further releases of any kind)
-The pre-release beta period would be relaxed to use the minor feature release
+The pre-release beta period would be relaxed to use the incremental feature
-policy for changes, rather than the stricter maintenance-only release policy.
+release policy for changes, rather than the stricter maintenance release policy.
-The existing "Maintenance" release series state would be renamed to
+For governance purposes, baseline feature releases are the only releases that
-"Maintenance only", as "Feature addition" releases are also maintenance
+would qualify as a "feature release" in the PEP 13 sense (incremental feature
-releases (just as maintenance releases can also be security fix releases).
+releases wouldn't count).
 For governance purposes, major feature releases are the only releases that
 would qualify as a "feature release" in the PEP 13 sense (minor feature releases
 wouldn't count).
-Major feature releases
+Baseline feature releases and major release series
----------------------
+--------------------------------------------------
-Major feature releases are just the existing feature releases, given a new name
+Baseline feature releases are essentially just the existing feature releases,
-to help distinguish them from the new minor feature releases.
+given a new name to help distinguish them from the new incremental feature
 releases, and also to help indicate that unlike their predecessors, they are
 no longer considered feature complete at release.
-Major feature releases would continue to define the following language, build,
+Baseline feature releases would continue to define a new major release series,
-and installation compatibility constraints:
+locking in the following language, build, and installation compatibility
 constraints for the remainder of that series:
 - Python language grammar
 - ``ast`` module AST format
@ -196,7 +208,7 @@ and installation compatibility constraints:
 - default package and module import directories
 - default installation filename and directories
-Major feature releases would also continue to be the only releases where:
+Baseline feature releases would also continue to be the only releases where:
 - new deprecations, pending deprecations, and other warnings can be introduced
 - existing pending deprecations can be converted to full deprecations
@ -204,31 +216,40 @@ Major feature releases would also continue to be the only releases where:
 - other changes requiring "Porting to Python X.Y" entries in the What's New
  document can be introduced
-Key characteristics of major feature releases:
+Key characteristics of a major release series:
- a major feature release installation does not conflict with installations of
+- an installation within one major release series does not conflict with
-  other major feature releases (i.e. they can be installed in parallel)
+  installations of other major release series (i.e. they can be installed in parallel)
- a major feature release installation can be updated to a later minor release
+- an installation within a major release series can be updated to a later minor
-  without requiring reinstallation or any other changes to previously installed
+  release within the same series without requiring reinstallation or any other
-  components
+  changes to previously installed components
- major feature releases may contain higher risk changes to the language and
+
 Key characteristics of a baseline feature release:
 - in a baseline feature release, ``sys.version_info.feature_complete == False``
 - in a baseline feature release, ``sys.version_info.minor == 0``
 - baseline feature releases may contain higher risk changes to the language and
  interpreter, such as grammar modifications, major refactoring of interpreter
-  and standard library internals, or potentially invasive feature additions with
+  and standard library internals, or potentially invasive feature additions that
-  a risk of unintended side effects on other existing functionality
+  carry a risk of unintended side effects on other existing functionality
 - features introduced in a baseline feature release are the *only* features
  permitted to rely on ``sys.version_info`` as their sole runtime indicator
  of the feature's availability
-Key expectations around major feature releases and release series:
+Key expectations around major release series and baseline feature releases:
 - most public projects will only actively test against the *most recent*
  minor release within a release series
 - many (most?) public projects will only add a new release series to their test
-  matrix *after* the initial feature release has already been published, which
+  matrix *after* the initial baseline feature release has already been published,
-  can make it difficult to resolve issues that require providing new flags or
+  which can make it difficult to resolve issues that require providing new flags
-  APIs to explicitly opt-in to old behaviour after a default behaviour changed
+  or APIs to explicitly opt-in to old behaviour after a default behaviour changed
 - private projects with known target environments will test against whichever
  minor release version they're actually using
 - most private projects will also only consider migrating to a new release
-  series *after* the initial feature release has already been published, again
+  series *after* the initial baseline feature release has already been published,
-  posing a problem if the resolution of their problems requires an API addition
+  again posing a problem if the resolution of their problems requires an API
  addition
 The key motivation of the proposal in this PEP is that the public and private
@ -240,19 +261,20 @@ handles them, rather than changing our processes in a way that then means the
 wider community needs to adjust to us rather than the other way around.
-Minor feature releases
+Incremental feature releases
----------------------
+----------------------------
-Minor feature releases are the key new process addition being proposed by this
+Incremental feature releases are the key new process addition being proposed by
-PEP. They are subject to the same strict runtime compatibility requirements
+this PEP. They are subject to the same strict runtime compatibility requirements
 as the existing maintenance releases, but would have the following more
 relaxed policies around API additions and enhancements:
 * new public APIs can be added to any standard library module (including builtins)
-* new optional arguments can be added to existing APIs (including builtins)
+* subject to the feature detection requirement below, new optional arguments can
  be added to existing APIs (including builtins)
 * new public APIs can be added to the stable C ABI (with appropriate version guards)
 * new public APIs can be added to the CPython C API
-* with the approval of the release manager, backwards compatible semantic
+* with the approval of the release manager, backwards compatible reliability
  improvements can be made to existing APIs and syntactic constructs
 * with the approval of the release manager, performance improvements can be
  incorporated for existing APIs and syntactic constructs
@ -262,17 +284,52 @@ The intent of this change in policy is to allow usability improvements for new
 rather than requiring users to incur the inherent delay and costs of waiting for
 and then upgrading to the next major release series.
-Key expectations around minor feature releases:
+Key characteristics of an incremental feature release:
 - in an incremental feature release, ``sys.version_info.feature_complete == False``
 - in an incremental feature release, ``sys.version_info.minor != 0``
 - all API additions made in an incremental feature release must support
  efficient runtime feature detection that doesn't rely on either
  ``sys.version_info`` or runtime code object introspection. In most cases, a
  simple ``hasattr`` check on the affected module will serve this purpose, but
  when it doesn't, an alternative approach will need to be implemented as part
  of the feature addition. Prior art in this area includes the
  ``pickle.HIGHEST_PROTOCOL`` attribute, the ``hashlib.algorithms_available``
  set, and the various ``os.supports_*`` sets that the ``os`` module already
  offers for platform dependent capability detection
 Key expectations around incremental feature releases:
 - "don't break existing installations on upgrade" remains a key requirement
-  for minor releases, even with the more permissive change inclusion policy
+  for all minor releases, even with the more permissive change inclusion policy
- more intrusive changes should still be deferred to the next major feature
+- more intrusive changes should still be deferred to the next baseline feature
  release
- public Python projects that start relying on features added in a minor feature
+- public Python projects that start relying on features added in an incremental
-  release should set their ``Python-Requires`` metadata appropriately (projects
+  feature release should set their ``Python-Requires`` metadata appropriately
-  already do this when necessary - e.g. ``aiohttp`` specifically requires
+  (projects already do this when necessary - e.g. ``aiohttp`` specifically
-  3.5.3 or later due to an issue with ``asyncio.get_event_loop()`` in earlier
+  requires 3.5.3 or later due to an issue with ``asyncio.get_event_loop()``
-  versions)
+  in earlier versions)
 Some standard library modules may also impose their own restrictions on
 acceptable changes in incremental feature releases (for example, new hash
 algorithms should only ever be added to ``hashlib.algorithms_guaranteed`` in
 a baseline feature release - incremental feature releases would only be
 permitted to add algorithms to ``hashlib.algorithms_available``)
 Feature complete release and subsequent maintenance releases
 ------------------------------------------------------------
 The feature complete release for a given major release series would be
 developed under the normal policy for an incremental feature release, but
 would have one distinguishing feature:
 - in a feature complete release, ``sys.version_info.feature_complete == True``
 Any subsequent maintenance and security fix only releases would also have that
 flag set, and may informally be referred to as "feature complete releases".
 For release series definition purposes though, the feature complete release
 is the first one that sets that flag to "True".
 Motivation
@ -283,8 +340,8 @@ for change in PEP 596: the current 18-24 month gap between feature releases has
 a lot of undesirable consequences, especially for the standard library (see
 PEP 596 for further articulation of the details).
-The concern with the specific proposal in PEP 596 is that it doubles the number
+This PEP's concern with the specific proposal in PEP 596 is that it doubles the
-of actively supported Python branches, increasing the complexity of
+number of actively supported Python branches, increasing the complexity of
 compatibility testing matrices for the entire Python community, increasing the
 number of binary Python wheels to be uploaded to PyPI when not using the stable
 ABI, and just generally having a high chance of inflicting a relatively high
@ -292,9 +349,10 @@ level of additional cost across the entire Python ecosystem.
 The view taken in this PEP is that there's an alternative approach that provides
 most of the benefits of a faster major release without actually incurring the
-associated costs: we can split the current X.Y.0 "feature freeze" into two parts,
+associated costs: we can split the current X.Y.0 "feature freeze" into two
-such that X.Y.0 only imposes a "runtime compatibility freeze", and the full
+parts, such that the baseline X.Y.0 release only imposes a
-feature freeze is deferred until later in the release series lifecycle.
+"runtime compatibility freeze", and the full standard library feature freeze
 is deferred until later in the release series lifecycle.
 Caveats and Limitations
@ -311,8 +369,8 @@ annual cadence for both contributors and end users, so adjustments ideally would
 be rare.
 This PEP does not dictate a specific cadence for minor releases within a release
-series - it just specifies the timelines for transitions between the release
+series - it just specifies the rouch timelines for transitions between the
-series lifecycle phases (pre-alpha, alpha, beta, feature additions,
+release series lifecycle phases (pre-alpha, alpha, beta, feature releases,
 bug fixes, security fixes). The number of minor releases within each phase is
 determined by the release manager for that series based on how frequently they
 and the rest of the release team for that series are prepared to undertake the
@ -321,7 +379,7 @@ associated work.
 However, for the sake of the example timelines, the PEP assumes quarterly
 minor releases (the cadence used for Python 3.6 and 3.7, splitting the
 difference between the twice yearly cadence used for some historical release
-series, and the monthly cadence expected for Python 3.8 and 3.9).
+series, and the monthly cadence planned for Python 3.8 and 3.9).
 Design Discussion
@ -335,15 +393,18 @@ in a major version update create additional work for large sections of the
 wider Python community.
 Decoupling those layout changes from the Python version numbering scheme is also
-something that in and of itself involves making backwards incompatible changes.
+something that would in and of itself involves making backwards incompatible
 changes, as well as adjusting community expectations around which versions will
 install over the top of each other, and which can be installed in parallel on
 a single system.
-We also don't have a straightforward means to communicate to the community "Only
+We also don't have a straightforward means to communicate to the community
-support major version X.Y until X.Y+1 is out, but support X.Z until X.Z+2 is
+variations in support periods like "Only support major version X.Y until
-out".
+X.Y+1 is out, but support X.Z until X.Z+2 is out".
 So this PEP takes as its starting assumption that the vast majority of Python
 users simply *shouldn't need to care* that we're changing our release policy,
-and the only folks that will be affected will be those that are eagerly waiting
+and the only folks that should be affected are those that are eagerly waiting
 for standard library improvements, and other backwards compatible interpreter
 enhancements.
@ -355,7 +416,7 @@ This PEP proposes that feature additions be limited to 12 months after the
 initial major feature release.
 The primary motivation for that is specifically to sync up with the Ubuntu LTS
-timing, such that the final minor feature release for Python 3.9.x gets
+timing, such that the feature complete release for the Python 3.9.x series gets
 published in October 2021, ready for inclusion in the Ubuntu 22.04 release.
 (other LTS Linux distributions like RHEL, SLES, and Debian don't have a fixed
 publishing cadence, so they can more easily tweak their LTS timing a bit to
@ -378,12 +439,12 @@ months of minor feature releases:
 * 2020-05: 3.9.0b3 (final beta release that locks ABI compatibility)
 * 2020-06: 3.9.0rc1
 * ... additional release candidates as determined by the release manager
-* 2020-07: 3.9.0
+* 2020-07: 3.9.0 (BFR)
-* 2020-10: 3.9.1
+* 2020-10: 3.9.1 (IFR)
-* 2021-01: 3.9.2
+* 2021-01: 3.9.2 (IFR)
-* 2021-04: 3.9.3
+* 2021-04: 3.9.3 (IFR)
-* 2021-07: 3.9.4
+* 2021-07: 3.9.4 (IFR)
-* 2021-10: 3.9.5 (final minor feature release)
+* 2021-10: 3.9.5
 * 2022-01: 3.9.6
 * 2022-04: 3.9.7
 * 2022-07: 3.9.8
@ -393,16 +454,16 @@ months of minor feature releases:
 This approach would mean there were still always two or three active branches,
 it's just that proportionally more time would be spent with a branch in the
-"feature additions" phase, as compared to the "pre-alpha", "pre-beta", and
+"feature releases" phase, as compared to the "pre-alpha", "pre-beta", and
 "pre-release" phases:
 * 2019-04 -> 2019-10: 3.9.0 pre-alpha, 3.8.0 pre-release, 3.7.x maintenance
 * 2019-10 -> 2020-03: 3.9.0 pre-beta, 3.8.x maintenance
 * 2020-03 -> 2020-07: 3.10.0 pre-alpha, 3.9.0 pre-release, 3.8.x maintenance
-* 2020-07 -> 2021-10: 3.10.0 pre-alpha, 3.9.x feature addition, 3.8.x maintenance
+* 2020-07 -> 2021-10: 3.10.0 pre-alpha, 3.9.x feature releases, 3.8.x maintenance
 * 2021-10 -> 2022-03: 3.10.0 pre-beta, 3.9.x maintenance
 * 2022-03 -> 2022-07: 3.11.0 pre-alpha, 3.10.0 pre-release, 3.9.x maintenance
-* 2022-07 -> 2023-10: 3.11.0 pre-alpha, 3.10.x feature addition, 3.9.x maintenance
+* 2022-07 -> 2023-10: 3.11.0 pre-alpha, 3.10.x feature releases, 3.9.x maintenance
 * 2023-10 -> 2024-03: 3.11.0 pre-beta, 3.10.x maintenance
 * 2024-03 -> 2024-07: 3.12.0 pre-alpha, 3.11.0 pre-release, 3.10.x maintenance
 * ... etc
@ -420,7 +481,7 @@ be backported to the most recent maintenance branch for 12 of those months.
 The variant of the proposal that moves the beta branch point earlier in the
 release series lifecycle would increase that period of no direct releases to
 21 months - the only period where releases were made directly from the main
-branch would be during the relatively short window between the last minor
+branch would be during the relatively short window between the last incremental
 feature release of the previous release series, and the beta branch point a
 few months later.
@ -445,9 +506,9 @@ Why not switch directly to full semantic versioning?
 ----------------------------------------------------
 If this were a versioning design document for a new language, it *would* use
-semantic versioning: the policies described above for major feature releases
+semantic versioning: the policies described above for baseline feature releases
-would be applied to X.0.0 releases, the policies for minor feature releases
+would be applied to X.0.0 releases, the policies for incremental feature
-would be applied to X.Y.0 releases, and the policies for maintenance only
+releases would be applied to X.Y.0 releases, and the policies for maintenance
 releases would be applied to X.Y.Z releases.
 The problem for Python specifically is that all the policies and properties for
@ -456,9 +517,9 @@ associated with the first *two* fields of the version number, and it has been
 that way for the better part of thirty years.
 As a result, it makes sense to split out the policy question of introducing
-minor feature releases in the first place from the technical question of making
+incremental feature releases in the first place from the technical question of
-the version numbering scheme better match the semantics of the different release
+making the version numbering scheme better match the semantics of the different
-types.
+release types.
 If the proposal in this PEP were to be accepted by the Steering Council for
 Python 3.9, then a better time to tackle that technical question would be for
@ -468,14 +529,16 @@ checks for the major version being exactly 3 rather than 3 or greater), or
 "Python 3.10" (code incorrectly assuming that the minor version will always
 contain exactly one decimal digit).
-There are complex pros and cons on both sides of that future choice, and this
+While the test of this PEP assumes that the release published in 2022 would be
-PEP would merely add one more potential pro in favour of choosing the
+3.10, there are complex pros and cons on both sides of that future choice, and
-"Python 4.0" option, with the caveat that we would also need to amend the
+this PEP does arguably add a potential pro in favour of choosing the
 "Python 4.0" option (with the caveat that we would also need to amend the
 affected installation layout and compatibility markers to only consider the
-major version number (rather than both the major and minor version).
+major version number, rather than both the major and minor version).
-If such a change were to be proposed and accepted, then the example 3.10.x
+If such a version numbering change were to be proposed and accepted, then the
-timeline given above would instead become the following 4.x series timeline:
+example 3.10.x timeline given above would instead become the following 4.x
 series timeline:
 * 2021-11: 4.0.0a1
 * ... additional alpha releases as determined by the release manager
@ -484,11 +547,11 @@ timeline given above would instead become the following 4.x series timeline:
 * 2022-08: 4.0.0bX (final beta release that locks ABI compatibility)
 * 2022-09: 4.0.0rc1
 * ... additional release candidates as determined by the release manager
-* 2022-10: 4.0.0
+* 2022-10: 4.0.0 (BFR)
-* 2023-01: 4.1.0
+* 2023-01: 4.1.0 (IFR)
-* 2023-04: 4.2.0
+* 2023-04: 4.2.0 (IFR)
-* 2023-07: 4.3.0
+* 2023-07: 4.3.0 (IFR)
-* 2023-10: 4.4.0 (final minor feature release)
+* 2023-10: 4.4.0 (IFR)
 * 2024-01: 4.4.1
 * 2024-04: 4.4.2
 * 2024-07: 4.4.3
@ -501,10 +564,10 @@ And the 5 year schedule forecast would look like:
 * 2019-04 -> 2019-10: 3.9.0 pre-alpha, 3.8.0 pre-release, 3.7.x maintenance
 * 2019-10 -> 2020-05: 3.9.0 pre-beta, 3.8.x maintenance
 * 2020-05 -> 2020-10: 4.0.0 pre-alpha, 3.9.0 pre-release, 3.8.x maintenance
-* 2020-10 -> 2021-10: 4.0.0 pre-alpha, 3.9.x feature addition, 3.8.x maintenance
+* 2020-10 -> 2021-10: 4.0.0 pre-alpha, 3.9.x feature releases, 3.8.x maintenance
 * 2021-10 -> 2022-05: 4.0.0 pre-beta, 3.9.x maintenance
 * 2022-05 -> 2022-10: 5.0.0 pre-alpha, 4.0.0 pre-release, 3.9.x maintenance
-* 2022-10 -> 2023-10: 5.0.0 pre-alpha, 4.x.0 feature addition, 3.9.x maintenance
+* 2022-10 -> 2023-10: 5.0.0 pre-alpha, 4.x.0 feature releases, 3.9.x maintenance
 * 2023-10 -> 2024-05: 5.0.0 pre-beta, 4.x.y maintenance
 * 2024-05 -> 2024-10: 6.0.0 pre-alpha, 5.0.0 pre-release, 4.x.y maintenance
 * ... etc