PEP 602 andPEP 605 describe two alternative approaches to delivering smallercollections of features to Python’s users more frequently (as compared to thecurrent approach of offering new feature releases every 18-24 months, withthe first binary alpha release taking place 6-8 months before the final release).
Both PEPs also propose moving to a release cadence that results in full releasesoccurring at a consistent time of year (every year forPEP 602, every otheryear forPEP 605).
This PEP (from the authors of both competing proposals) provides commonbackground onwhy a change in the release cadence is considered desirable,as well as the perceived risks that both PEPs attempt to mitigate.
When multiple large changes are delivered together, a complex investigationmay be required to determine the root cause of any new issues that arise.Large batch sizes also make it more likely that problemswill be encountered,given that they include larger pieces of relatively untested code.
The easiest way to simplify those investigations and reduce the likelihood ofusers encountering problems is to reduce the size of the batches being shipped.
PEP 602 proposes to address this problem via the straightforward approach ofreducing CPython’s typical batch size by 50%, shipping 12 months of changeseach time, rather than accumulating 18+ months of changes.
PEP 605 proposes to address it by regularly delivering 2 months worth of changesto a subset of Python’s user base that opts in to running a rolling stream ofbeta releases (similar to running Windows Insider builds instead of the Windowsretail release, or running Debian testing instead of Debian stable).
When only stable releases are seeing significant user adoption, and there’s along period of time between stable releases, it creates an incredibly strongtemptation for developers to push changes into stable releases before they’rereally ready for general use.
PEP 602 proposes to address this problem by reducing the period of timebetween stable releases to 12 months rather than 18 months.
PEP 605 proposes to address it by actively creating a community ofPython users that regularly install and use CPython beta releases, providing anincentive for core developers to start shipping changes earlier in thepre-release cycle, in order to obtain feedback before the feature gets lockeddown in a stable release.
While the current release cadence is nominally 18-24 months, in practice it hasconsistently been towards the 18 month end of that range. This means that thetarget dates for pre-releases and final releases move around from release torelease, and the only way to remember them is to either look at the release PEP,or else to add those dates to your calendar. This is annoying for bothindividual volunteers and for corporate contributors, and also complicatesalignment with events like PyCon US (typically April/May) and the now-annualcore development sprints (typically in September).
PEP 602 proposes to address this problem by publishing a new release in Octoberevery year, and basing the pre-release calendar for each year off that.
PEP 605 proposes to address this problem by alternating between release years(where a new stable release is published in August), and non-release years(where only maintenance releases and new rolling beta releases are published).
One of the challenges of designing changes to the core interpreter and standardlibrary APIs is that the user base in a position to provide feedback onnightly builds and the current pre-releases is relatively limited. This meansthat much user feedback isn’t received until after an API design has alreadyshipped in a full X.Y.0 release.
If the API is a regular API, then deprecation cycles mean that it may takeliterally years to correct any design mistakes identified at that point.Marking APIs as provisional nominally offers a way to avoid that constraint,but actually taking advantage of that freedom causes other problems.
PEP 602 proposes to address this problem by starting the alpha periodimmediately after the previous stable release.
PEP 605 proposes to address this problem by actively promoting adoption ofCPython pre-releases for running production workloads (not just for library andapplication compatibility testing), and adjusting the pre-release managementprocess as necessary to make that a reasonable thing to do.
(Note: some standard library APIs are amenable to initially being shipped aspart of separately versioned packages via PyPI, and only later incorporatedinto the standard library. This section is more about the lower level APIsand non-library features where that approach to obtaining early designfeedback doesn’t apply)
While the status quo could stand to be improved in some respects, Python’spopularity indicates that a lot of users and other participants in the widerPython ecosystem are happy enough with the current release management process.
Python’s user base is too large andtoo variedto cover all the potential downsides of changing our release cadence here, soinstead this section just covers some of the points that have been specificallytaken into account in the design of the PEPs.
It is already the case that not all users and redistributors update to everypublished CPython release series (for example, Debian stable and Ubuntu LTSsometimes skip releases due to the mismatch between their 24-month releasecycles and CPython’s typically 18-month cycle).
The faster 12-month full release cadence inPEP 602 means that users in thiscategory may end up skipping two releases where they would previously have onlyskipped one. However, the extended notice period for deprecations means thatskipping a single release should no longer result in missed deprecation warnings.
The slower 24-month full release cadence inPEP 605 may move some of the usersthat have historically been in this category into the “update to every stablerelease” category.
Many of Python’s users never install a pre-release, but do update to everystable release series at some point after it is published.
PEP 602 aims to mitigate the potential negative impact on members of this groupby keeping the minimum gap between releases to 12 months, and retaining the18 month full support period for each release.
Keeping the 18-month full support period for each release branch means that thebranches will spend roughly the same amount of time in full support andsecurity-fix-only mode as they do now (~18 months and ~42 months, respectively).
PEP 605 aims to mitigate the potential negative impact on members of this groupby increasing use during the pre-release period to achieve more stable finalreleases with wider ecosystem support at launch.
With a 24-month release cadence each release branch will spend proportionallymore time in full support mode and less time in security-fix-only mode(~24 months and ~36 months, respectively).
Full discussion of the impact on this group is left to the individual PEPs.
Despite the difficulties of doing so, there are already some users andredistributors that take on the challenge of using or publishing the CPythonmaster branch directly.
NeitherPEP 602 norPEP 605 should directly affect this group, but the rollingrelease stream proposal inPEP 605 aims to lower the barriers to more usersadopting this style of usage, by allowing them to adopt the tested rollingbeta stream, rather than needing to use the master branch directly.
For maintainers of third party libraries, the key source of support complexityis thenumber of different Python versions in widespread use.
PEP 602 aims to mitigate the potential negative impact on members of this groupby keeping the minimum gap between full releases to 12 months.
PEP 605 aims to mitigate the potential negative impact on members of this groupby increasing the gap between full releases to 24 months, retaining the currentpolicy of moving each release branch to security-fix-only mode not long afterits successor is released, and retaining the “beta” naming scheme for the newrolling release stream (at least for the Python 3.9 release cycle).
Full discussion of the impact on this group is left to the individual PEPs.
This document is placed in the public domain or under theCC0-1.0-Universal license, whichever is more permissive.
Source:https://github.com/python/peps/blob/main/peps/pep-0607.rst
Last modified:2025-02-01 08:59:27 GMT