1419 lines
105 KiB
HTML
1419 lines
105 KiB
HTML
|
|
|||
|
<!DOCTYPE html>
|
|||
|
<html lang="en">
|
|||
|
<head>
|
|||
|
<meta charset="utf-8">
|
|||
|
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
|||
|
<meta name="color-scheme" content="light dark">
|
|||
|
<title>PEP 605 – A rolling feature release stream for CPython | peps.python.org</title>
|
|||
|
<link rel="shortcut icon" href="../_static/py.png">
|
|||
|
<link rel="canonical" href="https://peps.python.org/pep-0605/">
|
|||
|
<link rel="stylesheet" href="../_static/style.css" type="text/css">
|
|||
|
<link rel="stylesheet" href="../_static/mq.css" type="text/css">
|
|||
|
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" media="(prefers-color-scheme: light)" id="pyg-light">
|
|||
|
<link rel="stylesheet" href="../_static/pygments_dark.css" type="text/css" media="(prefers-color-scheme: dark)" id="pyg-dark">
|
|||
|
<link rel="alternate" type="application/rss+xml" title="Latest PEPs" href="https://peps.python.org/peps.rss">
|
|||
|
<meta property="og:title" content='PEP 605 – A rolling feature release stream for CPython | peps.python.org'>
|
|||
|
<meta property="og:description" content="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 t...">
|
|||
|
<meta property="og:type" content="website">
|
|||
|
<meta property="og:url" content="https://peps.python.org/pep-0605/">
|
|||
|
<meta property="og:site_name" content="Python Enhancement Proposals (PEPs)">
|
|||
|
<meta property="og:image" content="https://peps.python.org/_static/og-image.png">
|
|||
|
<meta property="og:image:alt" content="Python PEPs">
|
|||
|
<meta property="og:image:width" content="200">
|
|||
|
<meta property="og:image:height" content="200">
|
|||
|
<meta name="description" content="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 t...">
|
|||
|
<meta name="theme-color" content="#3776ab">
|
|||
|
</head>
|
|||
|
<body>
|
|||
|
|
|||
|
<svg xmlns="http://www.w3.org/2000/svg" style="display: none;">
|
|||
|
<symbol id="svg-sun-half" viewBox="0 0 24 24" pointer-events="all">
|
|||
|
<title>Following system colour scheme</title>
|
|||
|
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none"
|
|||
|
stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
|
|||
|
<circle cx="12" cy="12" r="9"></circle>
|
|||
|
<path d="M12 3v18m0-12l4.65-4.65M12 14.3l7.37-7.37M12 19.6l8.85-8.85"></path>
|
|||
|
</svg>
|
|||
|
</symbol>
|
|||
|
<symbol id="svg-moon" viewBox="0 0 24 24" pointer-events="all">
|
|||
|
<title>Selected dark colour scheme</title>
|
|||
|
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none"
|
|||
|
stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
|
|||
|
<path stroke="none" d="M0 0h24v24H0z" fill="none"></path>
|
|||
|
<path d="M12 3c.132 0 .263 0 .393 0a7.5 7.5 0 0 0 7.92 12.446a9 9 0 1 1 -8.313 -12.454z"></path>
|
|||
|
</svg>
|
|||
|
</symbol>
|
|||
|
<symbol id="svg-sun" viewBox="0 0 24 24" pointer-events="all">
|
|||
|
<title>Selected light colour scheme</title>
|
|||
|
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none"
|
|||
|
stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
|
|||
|
<circle cx="12" cy="12" r="5"></circle>
|
|||
|
<line x1="12" y1="1" x2="12" y2="3"></line>
|
|||
|
<line x1="12" y1="21" x2="12" y2="23"></line>
|
|||
|
<line x1="4.22" y1="4.22" x2="5.64" y2="5.64"></line>
|
|||
|
<line x1="18.36" y1="18.36" x2="19.78" y2="19.78"></line>
|
|||
|
<line x1="1" y1="12" x2="3" y2="12"></line>
|
|||
|
<line x1="21" y1="12" x2="23" y2="12"></line>
|
|||
|
<line x1="4.22" y1="19.78" x2="5.64" y2="18.36"></line>
|
|||
|
<line x1="18.36" y1="5.64" x2="19.78" y2="4.22"></line>
|
|||
|
</svg>
|
|||
|
</symbol>
|
|||
|
</svg>
|
|||
|
<script>
|
|||
|
|
|||
|
document.documentElement.dataset.colour_scheme = localStorage.getItem("colour_scheme") || "auto"
|
|||
|
</script>
|
|||
|
<section id="pep-page-section">
|
|||
|
<header>
|
|||
|
<h1>Python Enhancement Proposals</h1>
|
|||
|
<ul class="breadcrumbs">
|
|||
|
<li><a href="https://www.python.org/" title="The Python Programming Language">Python</a> » </li>
|
|||
|
<li><a href="../pep-0000/">PEP Index</a> » </li>
|
|||
|
<li>PEP 605</li>
|
|||
|
</ul>
|
|||
|
<button id="colour-scheme-cycler" onClick="setColourScheme(nextColourScheme())">
|
|||
|
<svg aria-hidden="true" class="colour-scheme-icon-when-auto"><use href="#svg-sun-half"></use></svg>
|
|||
|
<svg aria-hidden="true" class="colour-scheme-icon-when-dark"><use href="#svg-moon"></use></svg>
|
|||
|
<svg aria-hidden="true" class="colour-scheme-icon-when-light"><use href="#svg-sun"></use></svg>
|
|||
|
<span class="visually-hidden">Toggle light / dark / auto colour theme</span>
|
|||
|
</button>
|
|||
|
</header>
|
|||
|
<article>
|
|||
|
<section id="pep-content">
|
|||
|
<h1 class="page-title">PEP 605 – A rolling feature release stream for CPython</h1>
|
|||
|
<dl class="rfc2822 field-list simple">
|
|||
|
<dt class="field-odd">Author<span class="colon">:</span></dt>
|
|||
|
<dd class="field-odd">Steve Dower <steve.dower at python.org>, Alyssa Coghlan <ncoghlan at gmail.com></dd>
|
|||
|
<dt class="field-even">Discussions-To<span class="colon">:</span></dt>
|
|||
|
<dd class="field-even"><a class="reference external" href="https://discuss.python.org/t/pep-605-a-rolling-feature-release-stream-for-cpython/2418">Discourse thread</a></dd>
|
|||
|
<dt class="field-odd">Status<span class="colon">:</span></dt>
|
|||
|
<dd class="field-odd"><abbr title="Formally declined and will not be accepted">Rejected</abbr></dd>
|
|||
|
<dt class="field-even">Type<span class="colon">:</span></dt>
|
|||
|
<dd class="field-even"><abbr title="Non-normative PEP containing background, guidelines or other information relevant to the Python ecosystem">Informational</abbr></dd>
|
|||
|
<dt class="field-odd">Created<span class="colon">:</span></dt>
|
|||
|
<dd class="field-odd">20-Sep-2019</dd>
|
|||
|
<dt class="field-even">Python-Version<span class="colon">:</span></dt>
|
|||
|
<dd class="field-even">3.9</dd>
|
|||
|
<dt class="field-odd">Post-History<span class="colon">:</span></dt>
|
|||
|
<dd class="field-odd">01-Oct-2019, 06-Oct-2019, 20-Oct-2019</dd>
|
|||
|
</dl>
|
|||
|
<hr class="docutils" />
|
|||
|
<section id="contents">
|
|||
|
<details><summary>Table of Contents</summary><ul class="simple">
|
|||
|
<li><a class="reference internal" href="#rejection-notice">Rejection Notice</a></li>
|
|||
|
<li><a class="reference internal" href="#abstract">Abstract</a></li>
|
|||
|
<li><a class="reference internal" href="#example-future-release-schedules">Example Future Release Schedules</a></li>
|
|||
|
<li><a class="reference internal" href="#example-future-release-announcements">Example Future Release Announcements</a><ul>
|
|||
|
<li><a class="reference internal" href="#suggested-what-s-new-in-python-3-9-entry">Suggested “What’s New in Python 3.9” Entry</a><ul>
|
|||
|
<li><a class="reference internal" href="#pep-605-changes-to-the-pre-release-management-process">PEP 605: Changes to the pre-release management process</a></li>
|
|||
|
</ul>
|
|||
|
</li>
|
|||
|
<li><a class="reference internal" href="#example-announcement-text-for-the-3-9-0a1-release">Example announcement text for the 3.9.0a1 release</a><ul>
|
|||
|
<li><a class="reference internal" href="#changes-to-the-pre-release-management-process">Changes to the pre-release management process</a></li>
|
|||
|
<li><a class="reference internal" href="#major-new-features-of-the-3-9-series-compared-to-3-8">Major new features of the 3.9 series, compared to 3.8</a></li>
|
|||
|
</ul>
|
|||
|
</li>
|
|||
|
<li><a class="reference internal" href="#example-announcement-text-for-the-3-9-0b2-release">Example announcement text for the 3.9.0b2 release</a></li>
|
|||
|
<li><a class="reference internal" href="#example-announcement-text-for-3-9-0a5-a-mid-stream-alpha-release">Example announcement text for 3.9.0a5 (a mid-stream alpha release)</a><ul>
|
|||
|
<li><a class="reference internal" href="#breaking-changes-in-the-full-cpython-abi-between-3-9-0b4-and-3-9-0a5">Breaking changes in the full CPython ABI between 3.9.0b4 and 3.9.0a5</a></li>
|
|||
|
</ul>
|
|||
|
</li>
|
|||
|
<li><a class="reference internal" href="#example-announcement-text-for-3-9-0rc1">Example announcement text for 3.9.0rc1</a><ul>
|
|||
|
<li><a class="reference internal" href="#preparation-for-the-final-3-9-0-release">Preparation for the final 3.9.0 release</a></li>
|
|||
|
<li><a class="reference internal" href="#id1">Major new features of the 3.9 series, compared to 3.8</a></li>
|
|||
|
</ul>
|
|||
|
</li>
|
|||
|
</ul>
|
|||
|
</li>
|
|||
|
<li><a class="reference internal" href="#motivation">Motivation</a></li>
|
|||
|
<li><a class="reference internal" href="#aims-of-this-proposal">Aims of this Proposal</a></li>
|
|||
|
<li><a class="reference internal" href="#proposal">Proposal</a><ul>
|
|||
|
<li><a class="reference internal" href="#two-year-cadence-for-stable-releases">Two year cadence for stable releases</a></li>
|
|||
|
<li><a class="reference internal" href="#merging-of-the-alpha-and-beta-phases-into-a-pre-freeze-phase">Merging of the alpha and beta phases into a “pre-freeze” phase</a><ul>
|
|||
|
<li><a class="reference internal" href="#pre-freeze-phase-duration-and-cadence">Pre-freeze phase duration and cadence</a></li>
|
|||
|
<li><a class="reference internal" href="#release-policy-for-beta-releases">Release policy for beta releases</a></li>
|
|||
|
<li><a class="reference internal" href="#release-policy-for-alpha-releases">Release policy for alpha releases</a></li>
|
|||
|
</ul>
|
|||
|
</li>
|
|||
|
<li><a class="reference internal" href="#release-candidate-policy-phase-duration-and-cadence">Release candidate policy, phase duration, and cadence</a></li>
|
|||
|
<li><a class="reference internal" href="#changes-to-management-of-the-cpython-stable-c-abi">Changes to management of the CPython stable C ABI</a></li>
|
|||
|
<li><a class="reference internal" href="#changes-to-management-of-the-full-cpython-abi">Changes to management of the full CPython ABI</a><ul>
|
|||
|
<li><a class="reference internal" href="#an-explicit-commit-and-news-file-convention-to-mark-abi-breaking-changes">An explicit commit and NEWS file convention to mark ABI breaking changes</a></li>
|
|||
|
<li><a class="reference internal" href="#explicitly-marking-builds-against-the-pre-freeze-abi">Explicitly marking builds against the pre-freeze ABI</a></li>
|
|||
|
</ul>
|
|||
|
</li>
|
|||
|
<li><a class="reference internal" href="#updating-python-requires-for-projects-affected-by-full-c-abi-changes">Updating Python-Requires for projects affected by full C ABI changes</a></li>
|
|||
|
</ul>
|
|||
|
</li>
|
|||
|
<li><a class="reference internal" href="#caveats-and-limitations">Caveats and Limitations</a></li>
|
|||
|
<li><a class="reference internal" href="#design-discussion">Design Discussion</a><ul>
|
|||
|
<li><a class="reference internal" href="#why-rolling-pre-freeze-releases-over-simply-doing-more-frequent-x-y-0-releases">Why rolling pre-freeze releases over simply doing more frequent X.Y.0 releases?</a></li>
|
|||
|
<li><a class="reference internal" href="#is-it-necessary-to-keep-the-alpha-and-beta-naming-scheme">Is it necessary to keep the “alpha” and “beta” naming scheme?</a></li>
|
|||
|
<li><a class="reference internal" href="#why-rolling-pre-freeze-releases-rather-than-alternating-between-stable-and-unstable-release-series">Why rolling pre-freeze releases rather than alternating between stable and unstable release series?</a></li>
|
|||
|
<li><a class="reference internal" href="#why-not-use-calendar-versioning-for-the-rolling-release-stream">Why not use Calendar Versioning for the rolling release stream?</a></li>
|
|||
|
<li><a class="reference internal" href="#how-would-users-of-the-rolling-pre-freeze-releases-detect-api-changes">How would users of the rolling pre-freeze releases detect API changes?</a></li>
|
|||
|
<li><a class="reference internal" href="#why-add-a-new-pre-freeze-abi-flag-to-force-rebuilds-after-x-y-0rc1">Why add a new pre-freeze ABI flag to force rebuilds after X.Y.0rc1?</a></li>
|
|||
|
<li><a class="reference internal" href="#why-allow-additional-alpha-releases-after-x-y-0a1">Why allow additional alpha releases after X.Y.0a1?</a></li>
|
|||
|
<li><a class="reference internal" href="#implications-for-cpython-core-development">Implications for CPython core development</a></li>
|
|||
|
<li><a class="reference internal" href="#implications-for-python-library-development">Implications for Python library development</a></li>
|
|||
|
<li><a class="reference internal" href="#implications-for-the-proposed-scientific-python-ecosystem-support-period">Implications for the proposed Scientific Python ecosystem support period</a></li>
|
|||
|
<li><a class="reference internal" href="#release-cycle-alignment-for-core-development-sprints">Release cycle alignment for core development sprints</a></li>
|
|||
|
<li><a class="reference internal" href="#release-cycle-alignment-for-prominent-linux-distributions">Release cycle alignment for prominent Linux distributions</a></li>
|
|||
|
<li><a class="reference internal" href="#implications-for-simple-deployment-environments">Implications for simple deployment environments</a></li>
|
|||
|
<li><a class="reference internal" href="#implications-for-complex-deployment-environments">Implications for complex deployment environments</a></li>
|
|||
|
</ul>
|
|||
|
</li>
|
|||
|
<li><a class="reference internal" href="#acknowledgements">Acknowledgements</a></li>
|
|||
|
<li><a class="reference internal" href="#references">References</a></li>
|
|||
|
<li><a class="reference internal" href="#copyright">Copyright</a></li>
|
|||
|
</ul>
|
|||
|
</details></section>
|
|||
|
<section id="rejection-notice">
|
|||
|
<h2><a class="toc-backref" href="#rejection-notice" role="doc-backlink">Rejection Notice</a></h2>
|
|||
|
<p>This PEP was rejected in favour of <a class="pep reference internal" href="../pep-0602/" title="PEP 602 – Annual Release Cycle for Python">PEP 602</a>. The potential alpha/beta alternation
|
|||
|
was deemed too confusing and the two year cadence between releases deemed too
|
|||
|
long.</p>
|
|||
|
</section>
|
|||
|
<section id="abstract">
|
|||
|
<h2><a class="toc-backref" href="#abstract" role="doc-backlink">Abstract</a></h2>
|
|||
|
<p>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. <a class="pep reference internal" href="../pep-0607/" title="PEP 607 – Reducing CPython’s Feature Delivery Latency">PEP 607</a> 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.</p>
|
|||
|
<p>The proposal in this PEP aims to allow CPython’s user base to self-select into
|
|||
|
two distinct but overlapping groups:</p>
|
|||
|
<ul class="simple">
|
|||
|
<li>users of stable feature releases (and their associated maintenance release
|
|||
|
streams) that are published every 24 months; and</li>
|
|||
|
<li>early adopters of a new rolling release stream that takes the place of the
|
|||
|
previous CPython pre-release process</li>
|
|||
|
</ul>
|
|||
|
<p>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”.</p>
|
|||
|
<p>Similarly, the guidance given for alpha releases would be amended to state
|
|||
|
“intended for library compatibility testing and the creation of ABI compatible
|
|||
|
binary artifacts”, rather than simply saying “not for production use”.</p>
|
|||
|
<p>The PEP authors believe these outcomes can be achieved by amending CPython’s
|
|||
|
pre-release management process as described in the Proposal section below.</p>
|
|||
|
<p>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).</p>
|
|||
|
</section>
|
|||
|
<section id="example-future-release-schedules">
|
|||
|
<h2><a class="toc-backref" href="#example-future-release-schedules" role="doc-backlink">Example Future Release Schedules</a></h2>
|
|||
|
<p>Under this proposal, Python 3.9.0a1 would be released in December 2019, two
|
|||
|
months after the Python 3.8.0 baseline feature release in October 2019.</p>
|
|||
|
<p>Assuming no further breaking changes were made to the full CPython ABI, the
|
|||
|
3.9.0b2 release would then follow 2 months later in February 2020, continuing
|
|||
|
through to 3.9.0b9 in April 2021.</p>
|
|||
|
<p>Any time a breaking change to the full CPython ABI was introduced, the first
|
|||
|
pre-release that included it would be marked as an alpha release.</p>
|
|||
|
<p>3.9.0rc1 would be published in June 2021, 3.9.0rc2 in July 2021, and then
|
|||
|
the full release published as 3.9.0 in August 2021.</p>
|
|||
|
<p>The cycle would start over again in October 2021, with the publication
|
|||
|
of 3.10.0a1 (4 months after the creation of the 3.9.x maintenance branch).</p>
|
|||
|
<p>The exact schedule of maintenance releases would be up to the release team,
|
|||
|
but assuming maintenance releases of 3.9.x were also to occur every other month
|
|||
|
(offset from the 3.10.0 beta releases), the overall release timeline
|
|||
|
would look like:</p>
|
|||
|
<ul class="simple">
|
|||
|
<li>2019-12: 3.9.0a1</li>
|
|||
|
<li>2020-02: 3.9.0b2</li>
|
|||
|
<li>… beta (or alpha) releases every other month</li>
|
|||
|
<li>2021-04: 3.9.0b9</li>
|
|||
|
<li>2021-06: 3.9.0rc1 (feature freeze, ABI freeze, pyc format freeze)</li>
|
|||
|
<li>2021-07: 3.9.0rc2</li>
|
|||
|
<li>2021-08: 3.9.0</li>
|
|||
|
<li>2021-09: 3.9.1, 3.8.x (final 3.8.x binary maintenance release)</li>
|
|||
|
<li>2021-10: 3.10.0a1</li>
|
|||
|
<li>2021-11: 3.9.2</li>
|
|||
|
<li>2021-12: 3.10.0b2</li>
|
|||
|
<li>… beta (or alpha) and maintenance releases continue in alternate months</li>
|
|||
|
<li>2023-04: 3.10.0b10</li>
|
|||
|
<li>2023-05: 3.9.11</li>
|
|||
|
<li>2023-06: 3.10.0rc1 (feature freeze, ABI freeze, pyc format freeze)</li>
|
|||
|
<li>2023-07: 3.10.0rc2, 3.9.12</li>
|
|||
|
<li>2023-08: 3.10.0</li>
|
|||
|
<li>2023-09: 3.10.1, 3.9.13 (final 3.9.x binary maintenance release)</li>
|
|||
|
<li>2023-10: 3.11.0a1</li>
|
|||
|
<li>2023-12: 3.11.0b2</li>
|
|||
|
<li>… etc</li>
|
|||
|
</ul>
|
|||
|
<p>If we assume two additional pre-releases were made that introduced breaking
|
|||
|
changes to the full CPython ABI in the 3.9.0a5 and 3.9.0a7 releases, then the
|
|||
|
overall calendar would look like:</p>
|
|||
|
<figure class="align-center" id="id14">
|
|||
|
<a class="reference internal image-reference" href="../_images/pep-0605-example-release-calendar.png"><img alt="../_images/pep-0605-example-release-calendar.png" src="../_images/pep-0605-example-release-calendar.png" style="width: 100%;" />
|
|||
|
</a>
|
|||
|
<figcaption>
|
|||
|
<p><span class="caption-text">Figure 1. Impact of the pre-release process changes on the calendar.</span></p>
|
|||
|
</figcaption>
|
|||
|
</figure>
|
|||
|
<p>There are always two or three active maintenance branches in this model,
|
|||
|
which preserves the status quo in that respect. The major difference is that
|
|||
|
we would start encouraging publishers to provide pre-built binaries for the
|
|||
|
pre-freeze rolling releases in addition to providing them for the stable
|
|||
|
maintenance branches.</p>
|
|||
|
<figure class="align-center" id="id15">
|
|||
|
<a class="reference internal image-reference" href="../_images/pep-0605-overlapping-support-matrix.png"><img alt="../_images/pep-0605-overlapping-support-matrix.png" src="../_images/pep-0605-overlapping-support-matrix.png" style="width: 50%;" />
|
|||
|
</a>
|
|||
|
<figcaption>
|
|||
|
<p><span class="caption-text">Figure 2. Testing matrix in the 18-month cadence vs. the 24-month</span></p>
|
|||
|
</figcaption>
|
|||
|
</figure>
|
|||
|
<p>Package publishers targeting the full CPython ABI that choose to provide
|
|||
|
pre-built binaries for the rolling pre-freeze releases would at least need
|
|||
|
to build new wheel archives following the 3.9.0a1 release. Whether they needed
|
|||
|
to publish updated binaries after subsequent alpha releases (e.g. 3.9.0a5 or
|
|||
|
3.9.0a7 releases in the example timeline) would depend on whether or not they
|
|||
|
were actually affected by the ABI breaks in those later releases.</p>
|
|||
|
<p>As with the status quo, all package publishers wishing to provide pre-built
|
|||
|
binaries for the final release will need to build new wheel archives following
|
|||
|
the ABI freeze date. Unlike the status quo, this date will be clearly marked
|
|||
|
by the publication of the first release candidate, and it will occur early
|
|||
|
enough to give publishers a couple of months to get ready for the final release.</p>
|
|||
|
</section>
|
|||
|
<section id="example-future-release-announcements">
|
|||
|
<h2><a class="toc-backref" href="#example-future-release-announcements" role="doc-backlink">Example Future Release Announcements</a></h2>
|
|||
|
<p>If this PEP is accepted, the primary channels used to communicate the updated
|
|||
|
pre-release management process to end users would be the Python 3.9 What’s New
|
|||
|
document, and the release announcements themselves.</p>
|
|||
|
<p>This section provides initial drafts of text that could be used for those
|
|||
|
purposes.</p>
|
|||
|
<section id="suggested-what-s-new-in-python-3-9-entry">
|
|||
|
<h3><a class="toc-backref" href="#suggested-what-s-new-in-python-3-9-entry" role="doc-backlink">Suggested “What’s New in Python 3.9” Entry</a></h3>
|
|||
|
<p>The following subsection would be added to the Python 3.9 What’s New document,
|
|||
|
and then linked from each of the Python 3.9 alpha and beta announcements.</p>
|
|||
|
<section id="pep-605-changes-to-the-pre-release-management-process">
|
|||
|
<h4><a class="toc-backref" href="#pep-605-changes-to-the-pre-release-management-process" role="doc-backlink">PEP 605: Changes to the pre-release management process</a></h4>
|
|||
|
<p>As detailed in <a class="pep reference internal" href="../pep-0605/" title="PEP 605 – A rolling feature release stream for CPython">PEP 605</a>, the pre-release management process has been updated to
|
|||
|
produce a rolling series of beta releases that are considered suitable for
|
|||
|
production use in environments with sufficiently robust integration testing and
|
|||
|
operational monitoring capabilities.</p>
|
|||
|
<p>Under this new rolling model, the alpha and beta releases are intermingled as
|
|||
|
part of a combined “pre-freeze” period, with alpha releases indicating breaks
|
|||
|
in the full CPython ABI that may require recompilation of extension modules or
|
|||
|
embedding applications, and beta releases indicating full binary compatibility
|
|||
|
with the immediately preceding pre-release.</p>
|
|||
|
<p>Unlike previous releases, publishing pre-built binaries for 3.9.0 alpha and beta
|
|||
|
releases is actively encouraged, as a new pre-release ABI flag (“p”) is now
|
|||
|
set when building and loading extension modules prior to the full CPython ABI
|
|||
|
freeze, ensuring that all such pre-freeze extension module builds will be
|
|||
|
ignored by post-freeze interpreter builds.</p>
|
|||
|
<p>The full CPython ABI will be frozen, and the pre-release flag dropped from the
|
|||
|
ABI flags, in 3.9.0rc1, which is expected to occur 2 months prior to the final
|
|||
|
3.9.0 release (refer to the release schedule in <a class="pep reference internal" href="../pep-0596/" title="PEP 596 – Python 3.9 Release Schedule">PEP 596</a> for exact target dates).</p>
|
|||
|
<p>For application developers, migrating to the rolling release stream provides
|
|||
|
the opportunity to be actively involved in the design and development of
|
|||
|
enhancements to the standard library and reference interpreter prior to the
|
|||
|
next stable release. It also provides the opportunity to benefit from
|
|||
|
interpreter performance enhancements up to a year or more before they become
|
|||
|
available in a stable release.</p>
|
|||
|
<p>For library developers that publish pre-built wheel archives, opting in to
|
|||
|
supporting the 3.9.x rolling release stream in addition to the 3.8 stable
|
|||
|
release series requires no specific action if the project is already publishing
|
|||
|
either pure Python wheels (tagged as <code class="docutils literal notranslate"><span class="pre">py3-none-any</span></code>), or builds against the
|
|||
|
stable C ABI (tagged as <code class="docutils literal notranslate"><span class="pre">cp38-abi3-<platform></span></code>, or the equivalent from an
|
|||
|
earlier CPython 3.x release). These same wheel archives will also be usable on
|
|||
|
the subsequent 3.9 stable release series.</p>
|
|||
|
<p>For library developers that publish pre-built wheel archives that are built
|
|||
|
against the full CPython ABI, the binaries for the 3.9 stable release series
|
|||
|
will need to be built after the full CPython ABI freeze (i.e. using 3.9.0rc1 or
|
|||
|
later).</p>
|
|||
|
<p>Developers of these libraries may also opt in to supporting the rolling release
|
|||
|
stream by building against the 3.9.0a1 release (or a subsequent beta release)
|
|||
|
and publishing the result as normal.</p>
|
|||
|
<p>In the ideal case, binaries built this way will continue working all the way
|
|||
|
through to the last pre-freeze release. However, if the project is affected by
|
|||
|
a change in the full CPython C ABI during the pre-freeze period, then it will
|
|||
|
be necessary to publish a maintenance update that rebuilds the affected binaries
|
|||
|
against the alpha release that changed the relevant interface. In these cases,
|
|||
|
a corresponding <code class="docutils literal notranslate"><span class="pre">Python-Requires</span></code> entry should be added to the project
|
|||
|
metadata. For example, if a project is affected by an ABI change introduced in
|
|||
|
<code class="docutils literal notranslate"><span class="pre">3.9.0a5</span></code>, then the <code class="docutils literal notranslate"><span class="pre">Python-Requires</span></code> entry to add would be:</p>
|
|||
|
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">Python</span><span class="o">-</span><span class="n">Requires</span><span class="p">:</span> <span class="o">>=</span> <span class="s2">"3.9.0b6"</span><span class="p">;</span> <span class="n">python_version</span> <span class="o">==</span> <span class="s2">"3.9"</span> <span class="ow">and</span> <span class="n">full_python_version</span> <span class="o">!=</span> <span class="s2">"3.9.0a5"</span>
|
|||
|
</pre></div>
|
|||
|
</div>
|
|||
|
<p>(This additional metadata ensures that the updated version won’t be installed on
|
|||
|
earlier pre-releases in the 3.9 series that offer an older variant of the ABI)</p>
|
|||
|
<p>As for application developers, library developers that choose to support the
|
|||
|
rolling release stream will have the opportunity to provide feedback on new and
|
|||
|
updated API designs <em>before</em> they’re locked down for multiple years in a stable
|
|||
|
release (or before they’re included as a provisional API in a stable release
|
|||
|
series).</p>
|
|||
|
</section>
|
|||
|
</section>
|
|||
|
<section id="example-announcement-text-for-the-3-9-0a1-release">
|
|||
|
<h3><a class="toc-backref" href="#example-announcement-text-for-the-3-9-0a1-release" role="doc-backlink">Example announcement text for the 3.9.0a1 release</a></h3>
|
|||
|
<p>This is the first preview release of Python 3.9. As an alpha release, it is
|
|||
|
intended for library and application compatibility testing and the creation of
|
|||
|
ABI compatible binary artifacts. It is not recommended for use in production
|
|||
|
environments.</p>
|
|||
|
<section id="changes-to-the-pre-release-management-process">
|
|||
|
<h4><a class="toc-backref" href="#changes-to-the-pre-release-management-process" role="doc-backlink">Changes to the pre-release management process</a></h4>
|
|||
|
<p>CPython has switched to a new pre-release management process that is designed
|
|||
|
to produce a rolling series of beta releases that are considered suitable for
|
|||
|
production use in environments with sufficiently robust integration testing and
|
|||
|
operational monitoring capabilities. Refer to the Python 3.9 What’s New
|
|||
|
document (hyperlinked to relevant section) for details.</p>
|
|||
|
</section>
|
|||
|
<section id="major-new-features-of-the-3-9-series-compared-to-3-8">
|
|||
|
<h4><a class="toc-backref" href="#major-new-features-of-the-3-9-series-compared-to-3-8" role="doc-backlink">Major new features of the 3.9 series, compared to 3.8</a></h4>
|
|||
|
<p>Many new features for Python 3.9 are still being planned and written. Among the
|
|||
|
major new features and changes already implemented:</p>
|
|||
|
<ul class="simple">
|
|||
|
<li>…</li>
|
|||
|
<li>(Hey, fellow core developer or user of the rolling release stream, if a
|
|||
|
feature you find important is missing from this list, let <the release
|
|||
|
manager> know.)</li>
|
|||
|
</ul>
|
|||
|
<p>The next pre-release of Python 3.9 is expected to be 3.8.0b2, currently scheduled for 2020-02-02.</p>
|
|||
|
</section>
|
|||
|
</section>
|
|||
|
<section id="example-announcement-text-for-the-3-9-0b2-release">
|
|||
|
<h3><a class="toc-backref" href="#example-announcement-text-for-the-3-9-0b2-release" role="doc-backlink">Example announcement text for the 3.9.0b2 release</a></h3>
|
|||
|
<p>This is the second preview release of Python 3.9. As a beta release, it is
|
|||
|
fully binary compatible with the preceding 3.9.0a1 release. It is recommended
|
|||
|
for production use only in environments with sufficiently robust integration
|
|||
|
testing and operational monitoring capabilities.</p>
|
|||
|
<p>(Remainder as per 3.9.0a1 announcement, with updates for implemented changes
|
|||
|
and the next expected release being 3.9.0b3)</p>
|
|||
|
</section>
|
|||
|
<section id="example-announcement-text-for-3-9-0a5-a-mid-stream-alpha-release">
|
|||
|
<h3><a class="toc-backref" href="#example-announcement-text-for-3-9-0a5-a-mid-stream-alpha-release" role="doc-backlink">Example announcement text for 3.9.0a5 (a mid-stream alpha release)</a></h3>
|
|||
|
<p>This is the fifth preview release of Python 3.9. As an alpha release, it is
|
|||
|
NOT fully binary compatible with the preceding 3.9.0b4 release. This release is
|
|||
|
intended for library and application compatibility testing and the creation of
|
|||
|
ABI compatible binary artifacts. It is not recommended for use in production
|
|||
|
environments.</p>
|
|||
|
<section id="breaking-changes-in-the-full-cpython-abi-between-3-9-0b4-and-3-9-0a5">
|
|||
|
<h4><a class="toc-backref" href="#breaking-changes-in-the-full-cpython-abi-between-3-9-0b4-and-3-9-0a5" role="doc-backlink">Breaking changes in the full CPython ABI between 3.9.0b4 and 3.9.0a5</a></h4>
|
|||
|
<ul class="simple">
|
|||
|
<li>new field <code class="docutils literal notranslate"><span class="pre">ob_example</span></code> added to the <code class="docutils literal notranslate"><span class="pre">PyObject</span></code> struct</li>
|
|||
|
<li>provisional field <code class="docutils literal notranslate"><span class="pre">tp_example</span></code> removed from the <code class="docutils literal notranslate"><span class="pre">PyTypeObject</span></code> struct</li>
|
|||
|
</ul>
|
|||
|
<p>Projects that are supporting the rolling release stream and require a rebuild
|
|||
|
to restore binary compatibility should add the following metadata to their
|
|||
|
updated release:</p>
|
|||
|
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">Python</span><span class="o">-</span><span class="n">Requires</span><span class="p">:</span> <span class="o">>=</span> <span class="s2">"3.9.0b6"</span><span class="p">;</span> <span class="n">python_version</span> <span class="o">==</span> <span class="s2">"3.9"</span> <span class="ow">and</span> <span class="n">full_python_version</span> <span class="o">!=</span> <span class="s2">"3.9.0a5"</span>
|
|||
|
</pre></div>
|
|||
|
</div>
|
|||
|
<p>(Remainder as per 3.9.0a1 announcement, with updates for implemented changes
|
|||
|
and the next expected release being 3.9.0b6)</p>
|
|||
|
</section>
|
|||
|
</section>
|
|||
|
<section id="example-announcement-text-for-3-9-0rc1">
|
|||
|
<h3><a class="toc-backref" href="#example-announcement-text-for-3-9-0rc1" role="doc-backlink">Example announcement text for 3.9.0rc1</a></h3>
|
|||
|
<p>This is the first release candidate for Python 3.9. As a release candidate,
|
|||
|
this release is now feature complete, the full CPython ABI is now frozen, and
|
|||
|
the pre-release marker has been removed from the ABI compatibility flags. It is
|
|||
|
recommended for production use only in environments with sufficiently robust
|
|||
|
integration testing and operational monitoring capabilities.</p>
|
|||
|
<section id="preparation-for-the-final-3-9-0-release">
|
|||
|
<h4><a class="toc-backref" href="#preparation-for-the-final-3-9-0-release" role="doc-backlink">Preparation for the final 3.9.0 release</a></h4>
|
|||
|
<p>With the full CPython ABI now frozen, library developers targeting that ABI are
|
|||
|
encouraged to build and publish binaries for the stable 3.9.x series.</p>
|
|||
|
<p>Application developers that have not been testing against the rolling release
|
|||
|
stream are encouraged to test their applications against the release candidate
|
|||
|
and report any compatibility regressions not already mentioned in the Porting
|
|||
|
Guide (hyperlinked to relevant What’s New section).</p>
|
|||
|
<p>A second release candidate is planned for 2021-07-02, and then the final 3.9.0
|
|||
|
release is planned for 2021-08-02.</p>
|
|||
|
</section>
|
|||
|
<section id="id1">
|
|||
|
<h4><a class="toc-backref" href="#id1" role="doc-backlink">Major new features of the 3.9 series, compared to 3.8</a></h4>
|
|||
|
<p>Some of the major new features and changes in this release:</p>
|
|||
|
<ul class="simple">
|
|||
|
<li>…</li>
|
|||
|
<li>(Hey, fellow core developer or user of the rolling release stream, if a
|
|||
|
feature you find important is missing from this list, let <the release
|
|||
|
manager> know.)</li>
|
|||
|
</ul>
|
|||
|
</section>
|
|||
|
</section>
|
|||
|
</section>
|
|||
|
<section id="motivation">
|
|||
|
<h2><a class="toc-backref" href="#motivation" role="doc-backlink">Motivation</a></h2>
|
|||
|
<p>The current CPython pre-release and release management processes were developed
|
|||
|
in an era where automated continuous integration and operational monitoring
|
|||
|
systems were still relatively immature. Since that time, many organisations
|
|||
|
have adopted deployment models that allow them to incorporate new CPython
|
|||
|
feature releases without adding substantially more risk than they incur for any
|
|||
|
other code change. Newer deployment models, such as lightweight task specific
|
|||
|
application containers, also make it easier to combine an application with a
|
|||
|
language runtime in a CI pipeline, and then keep them together until the entire
|
|||
|
container image is later replaced by an updated one.</p>
|
|||
|
<p>In light of those changes in the wider environment, <a class="pep reference internal" href="../pep-0602/" title="PEP 602 – Annual Release Cycle for Python">PEP 602</a> has proposed
|
|||
|
reducing the feature delivery latency for the Python standard library and
|
|||
|
CPython reference interpreter by increasing the frequency of CPython feature
|
|||
|
releases from every 18-24 months to instead occur every 12 months.</p>
|
|||
|
<p>Unfortunately, for many organisations, the cost of adopting a new Python release
|
|||
|
doesn’t automatically scale down with a reduced number of changes in the release,
|
|||
|
as the primary costs aren’t associated with resolving any discovered issues;
|
|||
|
the primary costs are associated with the <em>search</em> for issues. This search may
|
|||
|
involve manual testing of software systems, human review of written materials,
|
|||
|
and other activities where the time required scales with the size of the
|
|||
|
existing system, rather than with the number of changes between the versions of
|
|||
|
Python.</p>
|
|||
|
<p>For third party library developers, costs are primarily associated with the
|
|||
|
<em>number</em> of distinct Python versions in widespread usage. This currently tends
|
|||
|
to be influenced by a combination of which releases are still actively
|
|||
|
maintained by python-dev, and which releases are the latest versions offered
|
|||
|
by particular redistributors (with the Debian, Ubuntu LTS, and RHEL/CentOS
|
|||
|
system Python versions being particularly popular development targets). In
|
|||
|
addition to the basic CI cost of testing against more Python versions, having
|
|||
|
more variants in widespread use can make it more difficult to determine when a
|
|||
|
fault report is an actual error in the project, or an issue in the reporting
|
|||
|
user’s environment.</p>
|
|||
|
<p><a class="pep reference internal" href="../pep-0602/" title="PEP 602 – Annual Release Cycle for Python">PEP 602</a> proposes that affected organisations and projects simply switch to
|
|||
|
adopting every second or third CPython release, rather than attempting to adopt
|
|||
|
every release, but that creates its own set of new problems to be resolved, both
|
|||
|
practical (e.g. deprecations would need to cover more than one release if we’re
|
|||
|
expecting users to routinely skip releases) and cultural (e.g. with a larger
|
|||
|
number of versions in active use, there is a much higher chance that open source
|
|||
|
library maintainers will receive bug reports that only occur on Python versions
|
|||
|
that they’re not using themselves).</p>
|
|||
|
<p><a class="pep reference internal" href="../pep-0598/" title="PEP 598 – Introducing incremental feature releases">PEP 598</a> was an initial attempt by one of the authors of this PEP to propose
|
|||
|
an alternative scheme to reduce feature delivery latency by adopting a
|
|||
|
semantic versioning style policy that allowed for the incremental delivery of
|
|||
|
backwards compatible features within a release series, until that series
|
|||
|
reached feature complete status. That variant still had the undesirable
|
|||
|
consequence of imposing visible changes on end users that are happy enough
|
|||
|
with the current release management model.</p>
|
|||
|
<p>This PEP takes the view that both <a class="pep reference internal" href="../pep-0598/" title="PEP 598 – Introducing incremental feature releases">PEP 598</a> and <a class="pep reference internal" href="../pep-0602/" title="PEP 602 – Annual Release Cycle for Python">PEP 602</a> share a common flaw: they
|
|||
|
are attempting to satisfy the needs of two quite distinct audiences within the
|
|||
|
constraints of a single release model, which results in conflicting design
|
|||
|
requirements, and the need for awkward trade-offs between those conflicting
|
|||
|
requirements. The proposal in this PEP aims to avoid that flaw by proposing the
|
|||
|
creation of two <em>distinct</em> production-ready release streams, with the existing
|
|||
|
release stream being largely left alone, while the new release stream is
|
|||
|
tailored towards the audience that would most benefit from a reduction in
|
|||
|
feature delivery latency.</p>
|
|||
|
</section>
|
|||
|
<section id="aims-of-this-proposal">
|
|||
|
<h2><a class="toc-backref" href="#aims-of-this-proposal" role="doc-backlink">Aims of this Proposal</a></h2>
|
|||
|
<p>The proposal in this PEP arises from making the following key assumptions:</p>
|
|||
|
<ul class="simple">
|
|||
|
<li>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</li>
|
|||
|
<li>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)</li>
|
|||
|
<li>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</li>
|
|||
|
</ul>
|
|||
|
<p>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
|
|||
|
stability as to be suitable for use in appropriately managed production systems.</p>
|
|||
|
<p>By adopting this approach, the proposal aims to provide an improved outcome
|
|||
|
for almost all Python users and contributors:</p>
|
|||
|
<ul class="simple">
|
|||
|
<li>for users of the new incremental feature release stream, targeting the
|
|||
|
pre-release phase allows for even lower feature delivery latency than the
|
|||
|
annual cadence proposed in <a class="pep reference internal" href="../pep-0602/" title="PEP 602 – Annual Release Cycle for Python">PEP 602</a>;</li>
|
|||
|
<li>for core developers working on new features, increased frequency and adoption
|
|||
|
of pre-releases should improve pre-release feedback cycles;</li>
|
|||
|
<li>for users of the established release stream, the increased adoption and
|
|||
|
improved feedback cycles during the pre-release period should result in
|
|||
|
increased feature maturity at the time of its first X.Y.0 release, as well
|
|||
|
as higher levels of ecosystem readiness;</li>
|
|||
|
<li>for Python library maintainers, the rolling stream of pre-releases will
|
|||
|
hopefully provide more opportunities to identify and resolve design issues
|
|||
|
before they make it into a full stable release than is offered by the current
|
|||
|
pre-release management process; and</li>
|
|||
|
<li>for developers of alternative Python implementations, the rolling stream of
|
|||
|
pre-releases may provide an additional incentive for extension module authors
|
|||
|
to migrate from the full CPython ABI to the Python stable ABI, which would
|
|||
|
also serve to make more of the ecosystem compatible with implementations that
|
|||
|
don’t emulate the full CPython C API.</li>
|
|||
|
</ul>
|
|||
|
<p>That said, it is acknowledged that not all the outcomes of this proposal will be
|
|||
|
beneficial for all members of the wider Python ecosystem:</p>
|
|||
|
<ul class="simple">
|
|||
|
<li>for Python library maintainers, both this PEP and <a class="pep reference internal" href="../pep-0602/" title="PEP 602 – Annual Release Cycle for Python">PEP 602</a> would likely
|
|||
|
result in user pressure to support the faster release cadence. While this PEP
|
|||
|
attempts to mitigate that by clearly marking which pre-releases include
|
|||
|
potentially breaking changes to the full CPython C ABI, and <a class="pep reference internal" href="../pep-0602/" title="PEP 602 – Annual Release Cycle for Python">PEP 602</a> attempts
|
|||
|
to mitigate it by keeping the minimum time between full releases at
|
|||
|
12 months, it isn’t possible to eliminate this downside completely;</li>
|
|||
|
<li>for third party extension module maintainers, both this PEP and <a class="pep reference internal" href="../pep-0602/" title="PEP 602 – Annual Release Cycle for Python">PEP 602</a> would
|
|||
|
likely result in user pressure to start supporting the stable ABI in order to
|
|||
|
provide wheel archives that work on the new version as soon as it is
|
|||
|
available. Whether that’s a net negative or not will depend on how the request
|
|||
|
is presented to them (it could be a positive if the request comes in the form
|
|||
|
of a courteous contribution to their project from a developer interested in
|
|||
|
supporting the rolling pre-freeze releases);</li>
|
|||
|
<li>for some users of the established release stream that rely on the
|
|||
|
availability of pre-built wheel archives, switching to adopting a new release
|
|||
|
every 12 months may be an acceptable rate increase, while moving consistently
|
|||
|
to the 24 month end of the historical 18-24 month cadence would be an
|
|||
|
undesirable rate reduction relative to the 18-month cycle used for recent
|
|||
|
releases. Whether this proposal would be a net negative for these users will
|
|||
|
depend on whether or not we’re able to persuade library maintainers that
|
|||
|
it’s worth their while to support the upcoming stable release throughout its
|
|||
|
pre-freeze period, rather than waiting until its API and ABI have been
|
|||
|
frozen.</li>
|
|||
|
</ul>
|
|||
|
</section>
|
|||
|
<section id="proposal">
|
|||
|
<h2><a class="toc-backref" href="#proposal" role="doc-backlink">Proposal</a></h2>
|
|||
|
<p>The majority of the proposed changes in this PEP only affect the handling of
|
|||
|
pre-release versions. The one change affecting full release versions is a
|
|||
|
suggested change to their cadence.</p>
|
|||
|
<section id="two-year-cadence-for-stable-releases">
|
|||
|
<h3><a class="toc-backref" href="#two-year-cadence-for-stable-releases" role="doc-backlink">Two year cadence for stable releases</a></h3>
|
|||
|
<p>With the rolling pre-freeze releases available to users that are looking to
|
|||
|
use leading edge versions of the reference interpreter and standard library,
|
|||
|
this PEP proposes that the frequency of X.Y.0 releases be adjusted to publish
|
|||
|
a new stable release in August every two years (starting in 2021,
|
|||
|
around two years after the release of Python 3.8.0).</p>
|
|||
|
<p>This change is arguably orthogonal to the proposed changes to the handling of
|
|||
|
the pre-freeze release period, but the connection is that without those
|
|||
|
pre-release management changes, the downsides of a two-year full release cadence
|
|||
|
would probably outweigh the upsides, whereas the opposite is true for a
|
|||
|
12-month release cadence (i.e. with the pre-release management changes proposed
|
|||
|
in this PEP in place, the downsides of a 12-month full release cadence would
|
|||
|
outweigh the upsides).</p>
|
|||
|
</section>
|
|||
|
<section id="merging-of-the-alpha-and-beta-phases-into-a-pre-freeze-phase">
|
|||
|
<h3><a class="toc-backref" href="#merging-of-the-alpha-and-beta-phases-into-a-pre-freeze-phase" role="doc-backlink">Merging of the alpha and beta phases into a “pre-freeze” phase</a></h3>
|
|||
|
<p>Rather than continuing the status quo where the pre-release alpha and beta
|
|||
|
phases are distinct and sequential, this PEP proposes that they instead be
|
|||
|
combined into a single “pre-freeze” phase with a monotonically increasing serial
|
|||
|
number on the releases.</p>
|
|||
|
<p>Rather than denoting distinct phases, the “alpha” and “beta” names would
|
|||
|
instead indicate whether or not the release contains breaking changes to the
|
|||
|
full CPython C ABI:</p>
|
|||
|
<ul class="simple">
|
|||
|
<li>“alpha” releases would be “ABI breaking” releases where extension modules
|
|||
|
built against the full CPython ABI in the preceding pre-release are not
|
|||
|
necessarily going to load correctly</li>
|
|||
|
<li>“beta” releases would be “binary compatible” releases, where extension modules
|
|||
|
built against the full CPython ABI in the preceding pre-release are expected
|
|||
|
to load correctly, as long as those modules abide by the following additional
|
|||
|
criteria:<ul>
|
|||
|
<li>the module must not be using any provisional or private C APIs (either from
|
|||
|
the previous stable release series, or the in development pre-release series)
|
|||
|
that were removed in this beta release, or were changed in an ABI incompatible
|
|||
|
way</li>
|
|||
|
<li>the module must not be using any C APIs that were deprecated in the previous
|
|||
|
stable release series, and removed in this beta release</li>
|
|||
|
</ul>
|
|||
|
</li>
|
|||
|
</ul>
|
|||
|
<section id="pre-freeze-phase-duration-and-cadence">
|
|||
|
<h4><a class="toc-backref" href="#pre-freeze-phase-duration-and-cadence" role="doc-backlink">Pre-freeze phase duration and cadence</a></h4>
|
|||
|
<p>Rather than being released monthly for a period of a few months while preparing
|
|||
|
a new X.Y.0 release, pre-freeze releases would instead be consistently published
|
|||
|
every two months.</p>
|
|||
|
<p>The only time this would not be the case is during the two month release
|
|||
|
candidate period for an upcoming X.Y.0 release (see the release candidate
|
|||
|
section below for more details). This means two otherwise scheduled releases
|
|||
|
would be skipped (one corresponding with the first release candidate date, one
|
|||
|
with the final release date).</p>
|
|||
|
<p>The pre-freeze phase would typically be expected to start 2 months after the
|
|||
|
preceding stable X.Y.0 release.</p>
|
|||
|
<p>The first pre-freeze release for any new release series will always be X.Y.0a1
|
|||
|
(as there is no preceding release with the same ABI version markers to judge
|
|||
|
binary compatibility against).</p>
|
|||
|
<p>Pre-freeze releases would gain an additional flag in their C ABI compatibility
|
|||
|
markers to avoid binary compatibility issues with the eventual stable release.</p>
|
|||
|
</section>
|
|||
|
<section id="release-policy-for-beta-releases">
|
|||
|
<h4><a class="toc-backref" href="#release-policy-for-beta-releases" role="doc-backlink">Release policy for beta releases</a></h4>
|
|||
|
<p>This PEP proposes that the policy for beta releases be set as follows:</p>
|
|||
|
<ul class="simple">
|
|||
|
<li>as with current beta releases, the stable BuildBot fleet is expected to be
|
|||
|
green prior to preparation and publication of the beta release</li>
|
|||
|
<li>as with current beta releases, the release manager is expected to review
|
|||
|
open release blocker issues prior to preparation and publication of the beta
|
|||
|
release</li>
|
|||
|
<li>as with current beta releases, any additions to the <code class="docutils literal notranslate"><span class="pre">abi3</span></code> stable C ABI would
|
|||
|
be expected to become a permanent part of that ABI unless and until that
|
|||
|
stable ABI version is retired completely (Note: there are no current plans
|
|||
|
to increment the stable ABI version)</li>
|
|||
|
<li>unlike current beta releases, beta releases under this PEP would <em>not</em> be
|
|||
|
considered feature complete for the next X.Y.0 release</li>
|
|||
|
<li>unlike current beta releases, all APIs added since the last CPython feature
|
|||
|
release (other than additions to the stable C ABI) would be considered
|
|||
|
provisional</li>
|
|||
|
<li>unlike current beta releases, beta releases under this PEP would be prepared
|
|||
|
and published from the master development branch</li>
|
|||
|
<li>unlike current alpha or beta releases, beta releases under this PEP would be
|
|||
|
required to be fully ABI compatible with the immediately preceding pre-release
|
|||
|
in the series (excluding any changes to provisional APIs, or the removal of
|
|||
|
APIs that were deprecated in the previous release series)</li>
|
|||
|
</ul>
|
|||
|
</section>
|
|||
|
<section id="release-policy-for-alpha-releases">
|
|||
|
<h4><a class="toc-backref" href="#release-policy-for-alpha-releases" role="doc-backlink">Release policy for alpha releases</a></h4>
|
|||
|
<p>This PEP proposes that the policy for alpha releases be set as follows:</p>
|
|||
|
<ul class="simple">
|
|||
|
<li>as with current alpha releases, the stable BuildBot fleet is expected to be
|
|||
|
green prior to preparation and publication of the alpha release</li>
|
|||
|
<li>as with current alpha releases, the release manager is expected to review
|
|||
|
open release blocker issues prior to preparation and publication of the beta
|
|||
|
release</li>
|
|||
|
<li>unlike current alpha release, the release manager would be expected to
|
|||
|
target a similar level of stability to the current beta releases, even
|
|||
|
for the alpha releases</li>
|
|||
|
</ul>
|
|||
|
<p>Under this PEP, an alpha release would be published whenever it isn’t possible
|
|||
|
to publish a release that satisfies the criteria for a beta release, and
|
|||
|
allowing some additional time before making the release won’t resolve the issue.</p>
|
|||
|
<p>It is expected that the full CPython API changing in a way that breaks ABI
|
|||
|
compatibility (for example, a field may have been added to or removed from a
|
|||
|
public struct definition) will be the most likely reason for publishing
|
|||
|
additional alpha releases beyond the initial compatibility tag defining
|
|||
|
X.Y.0a1 release, but the decision for any particular release rests with the
|
|||
|
release manager.</p>
|
|||
|
</section>
|
|||
|
</section>
|
|||
|
<section id="release-candidate-policy-phase-duration-and-cadence">
|
|||
|
<h3><a class="toc-backref" href="#release-candidate-policy-phase-duration-and-cadence" role="doc-backlink">Release candidate policy, phase duration, and cadence</a></h3>
|
|||
|
<p>Given the proposed changes to the alpha and beta release phases, the release
|
|||
|
candidate phase would see the following related adjustments:</p>
|
|||
|
<ul class="simple">
|
|||
|
<li>Feature freeze, ABI freeze, pyc file format freeze, and maintenance branch
|
|||
|
creation would all correspond with the creation of X.Y.0rc1 (currently these
|
|||
|
occur across a mixture of X.Y.0b1, the last beta release, and X.Y.0rc1)</li>
|
|||
|
<li>The X.Y.0 release candidate period would be extended from 3 weeks to 2 months</li>
|
|||
|
<li>There would normally be two release candidates issued a month apart, but
|
|||
|
additional candidates may be published at the release manager’s discretion</li>
|
|||
|
<li>The final X.Y.0 release would occur between 1 and 4 weeks after the final
|
|||
|
release candidate (depending if additional release candidates were needed
|
|||
|
after the second)</li>
|
|||
|
<li>If the final X.Y.0 release is delayed beyond the August target date, the
|
|||
|
subsequent release series is not affected, and will still be scheduled for
|
|||
|
August (now slightly less than two years later).</li>
|
|||
|
</ul>
|
|||
|
<p>In addition to allowing more time for end user feedback on the release
|
|||
|
candidate, this adjusted policy also provides additional time for maintainers
|
|||
|
of Python projects to build and publish pre-built wheel archives for the new
|
|||
|
stable release series, significantly improving the initial user experience of
|
|||
|
the X.Y.0 release.</p>
|
|||
|
</section>
|
|||
|
<section id="changes-to-management-of-the-cpython-stable-c-abi">
|
|||
|
<h3><a class="toc-backref" href="#changes-to-management-of-the-cpython-stable-c-abi" role="doc-backlink">Changes to management of the CPython stable C ABI</a></h3>
|
|||
|
<p>The CPython stable ABI <a class="footnote-reference brackets" href="#id12" id="id2">[5]</a> makes the commitment that binary extension modules
|
|||
|
built against any particular CPython release will continue to work on future
|
|||
|
CPython releases that support the same stable ABI version (this version is
|
|||
|
currently <code class="docutils literal notranslate"><span class="pre">abi3</span></code>).</p>
|
|||
|
<p>Under the proposed rolling pre-freeze release model, this commitment would be
|
|||
|
extended to also apply to the beta releases: once an intentional addition to the
|
|||
|
<code class="docutils literal notranslate"><span class="pre">abi3</span></code> stable ABI for the upcoming Python version has been shipped in a beta
|
|||
|
release, then it will not be removed from future releases for as long as the
|
|||
|
<code class="docutils literal notranslate"><span class="pre">abi3</span></code> stable ABI remains supported.</p>
|
|||
|
<p>Two main mechanisms will be available for obtaining community feedback on
|
|||
|
additions to the stable ABI:</p>
|
|||
|
<ul class="simple">
|
|||
|
<li>the preferred mechanism will be to add new APIs to the full CPython API first,
|
|||
|
and only promote them to the stable ABI after they have been included in at
|
|||
|
least one published beta release and received relevant user feedback</li>
|
|||
|
<li>for APIs where that approach is unavailable for some reason (e.g. some API
|
|||
|
additions may serve no useful purpose when the full CPython API is available),
|
|||
|
then developers may request that the release manager mark the next release
|
|||
|
as an alpha release (even in the absence of an ABI break in the full CPython
|
|||
|
API), and attempt to obtain further feedback that way</li>
|
|||
|
</ul>
|
|||
|
<p>As a slight readability and usability improvement, this PEP also proposes the
|
|||
|
introduction of aliases for each major stable ABI version:</p>
|
|||
|
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="c1">#define Py_LIMITED_API_3_3 0x03030000</span>
|
|||
|
<span class="c1">#define Py_LIMITED_API_3_4 0x03040000</span>
|
|||
|
<span class="c1">#define Py_LIMITED_API_3_5 0x03050000</span>
|
|||
|
<span class="c1">#define Py_LIMITED_API_3_6 0x03060000</span>
|
|||
|
<span class="c1">#define Py_LIMITED_API_3_7 0x03070000</span>
|
|||
|
<span class="c1">#define Py_LIMITED_API_3_8 0x03080000</span>
|
|||
|
<span class="c1">#define Py_LIMITED_API_3_9 0x03090000</span>
|
|||
|
<span class="o">//</span> <span class="n">etc</span><span class="o">...</span>
|
|||
|
</pre></div>
|
|||
|
</div>
|
|||
|
<p>These would be used both in extension module code to set the target ABI
|
|||
|
version:</p>
|
|||
|
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="c1">#define Py_LIMITED_API Py_LIMITED_API_3_8</span>
|
|||
|
</pre></div>
|
|||
|
</div>
|
|||
|
<p>And also in the CPython interpreter implementation to check which symbols should
|
|||
|
be made available:</p>
|
|||
|
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="c1">#if !defined(Py_LIMITED_API) || Py_LIMITED_API+0 >= Py_LIMITED_API_3_9</span>
|
|||
|
<span class="o">//</span> <span class="n">A</span> <span class="n">Python</span> <span class="mf">3.9</span><span class="o">+</span> <span class="n">addition</span> <span class="n">to</span> <span class="n">the</span> <span class="n">stable</span> <span class="n">ABI</span> <span class="n">would</span> <span class="n">appear</span> <span class="n">here</span>
|
|||
|
<span class="c1">#endif</span>
|
|||
|
</pre></div>
|
|||
|
</div>
|
|||
|
<p>The documentation for the rolling pre-freeze releases and the stable C ABI would
|
|||
|
make it clear that extension modules built against the stable ABI in a later
|
|||
|
pre-freeze release may not load correctly on an earlier pre-freeze release.</p>
|
|||
|
<p>The documentation for alpha releases and the stable C ABI would make it clear
|
|||
|
that even extension modules built against the stable ABI in an alpha release
|
|||
|
may not load correctly on the next release if two alpha releases are published
|
|||
|
in a row (this situation would ideally be rare).</p>
|
|||
|
</section>
|
|||
|
<section id="changes-to-management-of-the-full-cpython-abi">
|
|||
|
<h3><a class="toc-backref" href="#changes-to-management-of-the-full-cpython-abi" role="doc-backlink">Changes to management of the full CPython ABI</a></h3>
|
|||
|
<p>This PEP proposes two changes to the management of the full CPython ABI.</p>
|
|||
|
<section id="an-explicit-commit-and-news-file-convention-to-mark-abi-breaking-changes">
|
|||
|
<h4><a class="toc-backref" href="#an-explicit-commit-and-news-file-convention-to-mark-abi-breaking-changes" role="doc-backlink">An explicit commit and NEWS file convention to mark ABI breaking changes</a></h4>
|
|||
|
<p>The proposal in this PEP requires that release managers be able to appropriately
|
|||
|
mark a pre-freeze release as either an alpha or a beta release based on whether
|
|||
|
or not it includes an ABI breaking change.</p>
|
|||
|
<p>To assist in that process, core developers would be requested to include a
|
|||
|
“(CPython ABI break)” marker at the beginning of all NEWS file snippets for
|
|||
|
changes that introduce a breaking change in the full CPython C ABI.</p>
|
|||
|
<p>The “CPython” marker is included to make it clear that these annotations relate
|
|||
|
to the full CPython ABI, not the stable ABI.</p>
|
|||
|
<p>For commit messages, the shorter marker “(ABI break)” would be placed at the
|
|||
|
start of the summary line for the commit.</p>
|
|||
|
<p>The pre-merge bots will be updated to ensure that if the ABI break marker
|
|||
|
appears in one of the two locations, it appears in both of them.</p>
|
|||
|
<p>If the marker is inadvertently omitted from the initial commit message and NEWS
|
|||
|
entry, then the commit message marker should be included in the subsequent
|
|||
|
commit that adds the marker to the NEWS entry.</p>
|
|||
|
<p>In addition to being useful for release managers, these markers should also be
|
|||
|
useful for developers investigating unexpected segfaults when testing against
|
|||
|
the affected release.</p>
|
|||
|
</section>
|
|||
|
<section id="explicitly-marking-builds-against-the-pre-freeze-abi">
|
|||
|
<h4><a class="toc-backref" href="#explicitly-marking-builds-against-the-pre-freeze-abi" role="doc-backlink">Explicitly marking builds against the pre-freeze ABI</a></h4>
|
|||
|
<p>The full CPython ABI has long operated under a policy where binary
|
|||
|
compatibility only applies within a release series after the ABI has been
|
|||
|
declared frozen, and only source compatibility applies between different
|
|||
|
release series.</p>
|
|||
|
<p>This policy means that extension modules built against CPython pre-releases
|
|||
|
prior to the ABI freeze for that release series may not actually load correctly
|
|||
|
on the final release.</p>
|
|||
|
<p>This is due to the fact that the extension module may be relying on provisional
|
|||
|
or previously deprecated interfaces that were changed or removed in a later
|
|||
|
alpha or beta release, or it may be due to public structures used by the
|
|||
|
extension module changing size due to the addition of new fields.</p>
|
|||
|
<p>Historically, adoption of alpha and beta releases has been low enough that this
|
|||
|
hasn’t really been a problem in practice. However, this PEP proposes to actively
|
|||
|
encourage widespread operational use of beta releases, which makes it desirable
|
|||
|
to ensure that users of those releases won’t inadvertently publish binary
|
|||
|
extension modules that cause segfaults for users running the release candidates
|
|||
|
and final releases.</p>
|
|||
|
<p>To that end, this PEP proposes amending the extension module <code class="docutils literal notranslate"><span class="pre">SOABI</span></code> marker
|
|||
|
on non-Windows systems to include a new “p” flag for CPython pre-releases, and
|
|||
|
only switch back to omitting that flag once the ABI for that particular X.Y.0
|
|||
|
version has been frozen on entry to the release candidate stage.</p>
|
|||
|
<p>With this change, alpha and beta releases of 3.9.0 would get an SOABI tag of
|
|||
|
<code class="docutils literal notranslate"><span class="pre">cpython-39p</span></code>, while all release candidates and final builds (for both 3.9.0
|
|||
|
and later 3.9.x releases) would get an unqualified SOABI tag of <code class="docutils literal notranslate"><span class="pre">cpython-39</span></code></p>
|
|||
|
<p>Debug builds would still add the “d” to the end of the tag, giving
|
|||
|
<code class="docutils literal notranslate"><span class="pre">cpython-39pd</span></code> for debug builds of pre-releases.</p>
|
|||
|
<p>On Windows systems, the suffix for tagged <code class="docutils literal notranslate"><span class="pre">pyd</span></code> files in pre-release builds
|
|||
|
would include “p” as a pre-release marker immediately after the version number,
|
|||
|
giving markers like “cp39p-win_amd64”.</p>
|
|||
|
<p>A proposed reference implementation for this change is available at <a class="footnote-reference brackets" href="#id11" id="id3">[4]</a> (Note:
|
|||
|
at time of writing, that implementation had not yet been tested on Windows).</p>
|
|||
|
</section>
|
|||
|
</section>
|
|||
|
<section id="updating-python-requires-for-projects-affected-by-full-c-abi-changes">
|
|||
|
<h3><a class="toc-backref" href="#updating-python-requires-for-projects-affected-by-full-c-abi-changes" role="doc-backlink">Updating Python-Requires for projects affected by full C ABI changes</a></h3>
|
|||
|
<p>When a project first opts in to providing pre-built binary wheels for the
|
|||
|
rolling pre-freeze release series, they don’t need to do anything special: they
|
|||
|
would add the rolling release series to their build and test matrices and
|
|||
|
publish binary archives that are flagged as being compatible with that release
|
|||
|
series, just as they would if providing pre-built binary wheels after the
|
|||
|
full CPython ABI freeze for that release series.</p>
|
|||
|
<p>However, if the project is affected by a CPython ABI compatibility break in the
|
|||
|
rolling release stream, then they will need to issue a version update that
|
|||
|
includes both the new binary build, and a new environment constrained
|
|||
|
<code class="docutils literal notranslate"><span class="pre">Python-Requires</span></code> marker.</p>
|
|||
|
<p>For example, if a project supporting the rolling release stream was affected by
|
|||
|
a CPython ABI compatibility break in the 3.9.0a5 release, then they would add
|
|||
|
the following metadata entry on the version that published the updated binary
|
|||
|
build:</p>
|
|||
|
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">Python</span><span class="o">-</span><span class="n">Requires</span><span class="p">:</span> <span class="o">>=</span> <span class="s2">"3.9.0b6"</span><span class="p">;</span> <span class="n">python_version</span> <span class="o">==</span> <span class="s2">"3.9"</span> <span class="ow">and</span> <span class="n">full_python_version</span> <span class="o">!=</span> <span class="s2">"3.9.0a5"</span>
|
|||
|
</pre></div>
|
|||
|
</div>
|
|||
|
<p>What this does is add an additional compatibility constraint as part of the
|
|||
|
published packages, so Python 3.9.0 beta versions prior to 3.9.0b6 won’t
|
|||
|
consider the updated package as a candidate for installation, and the only
|
|||
|
alpha release that will consider the package is 3.9.0a5 itself.</p>
|
|||
|
</section>
|
|||
|
</section>
|
|||
|
<section id="caveats-and-limitations">
|
|||
|
<h2><a class="toc-backref" href="#caveats-and-limitations" role="doc-backlink">Caveats and Limitations</a></h2>
|
|||
|
<p>Actual release dates may be scheduled up to a month earlier or later at
|
|||
|
the discretion of the release manager, based on release team availability, and
|
|||
|
the timing of other events (e.g. PyCon US, or the annual core developer
|
|||
|
sprints). However, as one goal of the proposal is to provide a consistent
|
|||
|
release cadence, adjustments should ideally be rare.</p>
|
|||
|
<p>Within a release series, the exact frequency of maintenance releases would
|
|||
|
still be up to the release manager and the binary release team; this PEP
|
|||
|
only proposes an expected cadence for pre-releases and X.Y.0 releases.</p>
|
|||
|
<p>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.</p>
|
|||
|
<p>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):</p>
|
|||
|
<ul class="simple">
|
|||
|
<li>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.</li>
|
|||
|
<li>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</li>
|
|||
|
<li>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.</li>
|
|||
|
</ul>
|
|||
|
<p>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.</p>
|
|||
|
</section>
|
|||
|
<section id="design-discussion">
|
|||
|
<h2><a class="toc-backref" href="#design-discussion" role="doc-backlink">Design Discussion</a></h2>
|
|||
|
<section id="why-rolling-pre-freeze-releases-over-simply-doing-more-frequent-x-y-0-releases">
|
|||
|
<h3><a class="toc-backref" href="#why-rolling-pre-freeze-releases-over-simply-doing-more-frequent-x-y-0-releases" role="doc-backlink">Why rolling pre-freeze releases over simply doing more frequent X.Y.0 releases?</a></h3>
|
|||
|
<p>For large parts of Python’s user base, <em>availability</em> of new CPython feature
|
|||
|
releases isn’t the limiting factor on their adoption of those new releases
|
|||
|
(this effect is visible in such metrics as PyPI download metadata).</p>
|
|||
|
<p>As such, any proposal based on speeding up full feature releases needs to strike
|
|||
|
a balance between meeting the needs of users who would be adopting each release
|
|||
|
as it became available, and those that would now be in a position of adopting
|
|||
|
every 2nd, 3rd, or 4th release, rather than being able to migrate to almost
|
|||
|
every release at some point within its lifecycle.</p>
|
|||
|
<p>This proposal aims to approach the problem from a different angle by defining a
|
|||
|
<em>new</em> production-ready release stream that is more specifically tailored to the
|
|||
|
interests of operating environments that are able to consume new releases as
|
|||
|
fast as the CPython core team is prepared to produce them.</p>
|
|||
|
</section>
|
|||
|
<section id="is-it-necessary-to-keep-the-alpha-and-beta-naming-scheme">
|
|||
|
<h3><a class="toc-backref" href="#is-it-necessary-to-keep-the-alpha-and-beta-naming-scheme" role="doc-backlink">Is it necessary to keep the “alpha” and “beta” naming scheme?</a></h3>
|
|||
|
<p>Using the “a” and “b” initials for the proposed rolling releases is a design
|
|||
|
constraint imposed by some of the pragmatic aspects of the way CPython version
|
|||
|
numbers are published.</p>
|
|||
|
<p>Specifically, alpha releases, beta releases, and release candidates are reported
|
|||
|
in some places using the strings “a”, “b”, and “c” respectively, while in others
|
|||
|
they’re reported using the hex digits <code class="docutils literal notranslate"><span class="pre">0xA</span></code>, <code class="docutils literal notranslate"><span class="pre">0xB</span></code>, and <code class="docutils literal notranslate"><span class="pre">0xC</span></code>. We want to
|
|||
|
preserve that, while also ensuring that any <code class="docutils literal notranslate"><span class="pre">Python-Requires</span></code> constraints
|
|||
|
are expressed against the beta releases rather than the alpha releases (since
|
|||
|
the latter may not enforce the <code class="docutils literal notranslate"><span class="pre">abi3</span></code> stability requirements if two alpha
|
|||
|
releases occur in succession).</p>
|
|||
|
<p>However, there isn’t anything forcing us to say that the “a” stands for “alpha”
|
|||
|
or the “b” stands for “beta”.</p>
|
|||
|
<p>That means that if we wanted to increase adoption amongst folks that were
|
|||
|
only being put off by the “beta” label, then it may make sense to emphasise
|
|||
|
the “*A*BI breaking” and “*B*inary compatible” names over the “alpha”
|
|||
|
and “beta” names, giving:</p>
|
|||
|
<ul class="simple">
|
|||
|
<li>3.9.0a1: ABI breaking pre-freeze release</li>
|
|||
|
<li>3.9.0b2: binary compatible pre-freeze release</li>
|
|||
|
<li>3.9.0rc1: release candidate</li>
|
|||
|
<li>3.9.0: final release</li>
|
|||
|
</ul>
|
|||
|
<p>This iteration of the PEP doesn’t go that far, as limiting initial adoption
|
|||
|
of the rolling pre-freeze releases to folks that are comfortable with the
|
|||
|
“beta” label is likely to be a good thing, as it is the early adopters of these
|
|||
|
releases that are going to encounter any unexpected consequences that occur
|
|||
|
at the level of the wider Python ecosystem, and we’re going to need them to
|
|||
|
be willing to take an active part in getting those issues resolved.</p>
|
|||
|
<p>Moving away from the “beta” naming would then become an option to keep in mind
|
|||
|
for the future, assuming the resulting experience is sufficiently positive that
|
|||
|
we decide the approach is worth continuing.</p>
|
|||
|
</section>
|
|||
|
<section id="why-rolling-pre-freeze-releases-rather-than-alternating-between-stable-and-unstable-release-series">
|
|||
|
<h3><a class="toc-backref" href="#why-rolling-pre-freeze-releases-rather-than-alternating-between-stable-and-unstable-release-series" role="doc-backlink">Why rolling pre-freeze releases rather than alternating between stable and unstable release series?</a></h3>
|
|||
|
<p>Rather than using the beta period for rolling releases, another option would be
|
|||
|
to alternate between traditional stable releases (for 3.8.x, 3.10.x, etc), and
|
|||
|
release series that used the new rolling release cadence (for 3.9.x, 3.11.x,
|
|||
|
etc).</p>
|
|||
|
<p>This idea suffers from the same core problem as <a class="pep reference internal" href="../pep-0598/" title="PEP 598 – Introducing incremental feature releases">PEP 598</a> and <a class="pep reference internal" href="../pep-0602/" title="PEP 602 – Annual Release Cycle for Python">PEP 602</a>: it imposes
|
|||
|
changes on end users that are happy with the status quo without offering them
|
|||
|
any clear compensating benefit.</p>
|
|||
|
<p>It’s also affected by one of the main concerns raised against <a class="pep reference internal" href="../pep-0598/" title="PEP 598 – Introducing incremental feature releases">PEP 598</a>: at least
|
|||
|
some core developers and end users strongly prefer that no particular semantics
|
|||
|
be assigned to the <em>value</em> of any of the numbers in a release version. These
|
|||
|
community members instead prefer that all the semantic significance be
|
|||
|
associated with the <em>position</em> within the release number that is changing.</p>
|
|||
|
<p>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.</p>
|
|||
|
</section>
|
|||
|
<section id="why-not-use-calendar-versioning-for-the-rolling-release-stream">
|
|||
|
<h3><a class="toc-backref" href="#why-not-use-calendar-versioning-for-the-rolling-release-stream" role="doc-backlink">Why not use Calendar Versioning for the rolling release stream?</a></h3>
|
|||
|
<p>Steve Dower’s initial write-up of this proposal <a class="footnote-reference brackets" href="#id8" id="id4">[1]</a> suggested the use of
|
|||
|
calendar versioning for the rolling release stream (so the first rolling
|
|||
|
pre-release after Python 3.8.0 would have been Python 2019.12 rather than
|
|||
|
3.9.0b1).</p>
|
|||
|
<p>Paul Moore pointed out <a class="footnote-reference brackets" href="#id9" id="id5">[2]</a> two major practical problems with that proposal:</p>
|
|||
|
<ul class="simple">
|
|||
|
<li>it isn’t going to be clear to users of the calendar-based versions where they
|
|||
|
stand in relation to the traditionally numbered versions</li>
|
|||
|
<li>it breaks <code class="docutils literal notranslate"><span class="pre">Python-Requires</span></code> metadata processing in packaging tools with
|
|||
|
no clear way of fixing it reliably (since all calendar versions would appear
|
|||
|
as newer than any standard version)</li>
|
|||
|
</ul>
|
|||
|
<p>This PEP aims to address both of those problems by using the established beta
|
|||
|
version numbers for the rolling releases.</p>
|
|||
|
<p>As an example, consider the following question: “Does Python 2021.12 include
|
|||
|
all the new features released in Python 3.9.0?”. With calendar versioning on
|
|||
|
the rolling releases, that’s impossible to answer without consulting a release
|
|||
|
calendar to see when 3.9.0rc1 was branched off from the rolling release series.</p>
|
|||
|
<p>By contrast, the equivalent question for rolling pre-freeze releases is
|
|||
|
straightforward to answer: “Does Python 3.10.0b2 include all the new features
|
|||
|
released in Python 3.9.0?”. Just from formulating the question, the answer is
|
|||
|
clearly “Yes, unless they were provisional features that got removed”.</p>
|
|||
|
<p>The beta numbering approach also avoids other questions raised by the calendar
|
|||
|
versioning concept, such as how <code class="docutils literal notranslate"><span class="pre">sys.version_info</span></code>, <code class="docutils literal notranslate"><span class="pre">PY_VERSION_HEX</span></code>,
|
|||
|
<code class="docutils literal notranslate"><span class="pre">site-packages</span></code> directory naming, and installed Python binary and extension
|
|||
|
module naming would work.</p>
|
|||
|
</section>
|
|||
|
<section id="how-would-users-of-the-rolling-pre-freeze-releases-detect-api-changes">
|
|||
|
<h3><a class="toc-backref" href="#how-would-users-of-the-rolling-pre-freeze-releases-detect-api-changes" role="doc-backlink">How would users of the rolling pre-freeze releases detect API changes?</a></h3>
|
|||
|
<p>When adding new features, core developers would be strongly encouraged to
|
|||
|
support feature detection and graceful fallback to alternative approaches via
|
|||
|
mechanisms that don’t rely on either <code class="docutils literal notranslate"><span class="pre">sys.version_info</span></code> or runtime code object
|
|||
|
introspection.</p>
|
|||
|
<p>In most cases, a simple <code class="docutils literal notranslate"><span class="pre">hasattr</span></code> check on the affected module will serve this
|
|||
|
purpose, but when it doesn’t, alternative approaches would be considered as part
|
|||
|
of the feature addition. Prior art in this area includes the
|
|||
|
<code class="docutils literal notranslate"><span class="pre">pickle.HIGHEST_PROTOCOL</span></code> attribute, the <code class="docutils literal notranslate"><span class="pre">hashlib.algorithms_available</span></code> set,
|
|||
|
and the various <code class="docutils literal notranslate"><span class="pre">os.supports_*</span></code> sets that the <code class="docutils literal notranslate"><span class="pre">os</span></code> module already offers for
|
|||
|
platform dependent capability detection.</p>
|
|||
|
<p>It would also be possible to add features that need to be explicitly enabled
|
|||
|
via a <code class="docutils literal notranslate"><span class="pre">__future__</span></code> import when first included in the rolling pre-freeze releases,
|
|||
|
even if that feature flag was subsequently enabled by default before its first
|
|||
|
appearance in an X.Y.0 release candidate.</p>
|
|||
|
<p>The rationale behind these approaches is that explicit detection/enabling like
|
|||
|
this would make it straightforward for users of the rolling pre-freeze release
|
|||
|
stream to notice when we remove or change provisional features
|
|||
|
(e.g. <code class="docutils literal notranslate"><span class="pre">from</span> <span class="pre">__future__</span></code> imports break on compile if the feature flag no
|
|||
|
longer exists), or to safely fall back on previous functionality.</p>
|
|||
|
<p>The interpreter’s rich attribute lookup machinery means we can also choose to
|
|||
|
add warnings for provisional or deprecated imports and attributes that we don’t
|
|||
|
have any practical way to add for checks against the value of
|
|||
|
<code class="docutils literal notranslate"><span class="pre">sys.version_info</span></code>.</p>
|
|||
|
</section>
|
|||
|
<section id="why-add-a-new-pre-freeze-abi-flag-to-force-rebuilds-after-x-y-0rc1">
|
|||
|
<h3><a class="toc-backref" href="#why-add-a-new-pre-freeze-abi-flag-to-force-rebuilds-after-x-y-0rc1" role="doc-backlink">Why add a new pre-freeze ABI flag to force rebuilds after X.Y.0rc1?</a></h3>
|
|||
|
<p>The core development team currently actively <em>discourage</em> the creation of
|
|||
|
public pre-built binaries for an X.Y series prior to the ABI freeze date.</p>
|
|||
|
<p>The reason we do that is to avoid the risk of painful debugging sessions
|
|||
|
on the stable X.Y.0 release that get traced back to “Oh, our dependency
|
|||
|
‘superfast-binary-operation’ was affected by a CPython ABI break in
|
|||
|
X.Y.0a3, but the project hasn’t published a new build since then”.</p>
|
|||
|
<p>With the proposed pre-freeze ABI flag in place, this aspect of the
|
|||
|
release adoption process continues on essentially unchanged from the
|
|||
|
status quo: a new CPython X.Y release series hits ABI freeze -> package
|
|||
|
maintainers publish new binary extension modules for that release
|
|||
|
series -> end users only get segfaults due to actual bugs, not just
|
|||
|
builds against an incompatible ABI.</p>
|
|||
|
<p>The primary goal of the new pre-freeze ABI flag is then to improve
|
|||
|
the user experience of the rolling pre-freeze releases themselves, by
|
|||
|
allowing pre-built binary archives to be published for those releases
|
|||
|
without risking the problems that currently cause us to actively
|
|||
|
discourage the publication of binary artifacts prior to ABI freeze.</p>
|
|||
|
<p>In the ideal case, package maintainers will only need to publish
|
|||
|
one pre-freeze binary build at X.Y.0a1, and then a post-freeze
|
|||
|
build after X.Y.0rc1. The only situations that should <em>require</em>
|
|||
|
a rebuild in the meantime are those where the project was
|
|||
|
actually affected by a CPython ABI break in an intervening alpha
|
|||
|
release.</p>
|
|||
|
<p>As a concrete example, consider the scenario where we end up having three
|
|||
|
releases that include ABI breaks: X.Y.0a1, X.Y.0a5, X.Y.0a7. The X.Y.0a7 ABI is
|
|||
|
then the ABI that carries through all the subsequent beta releases and into
|
|||
|
X.Y.0rc1. (This is the scenario illustrated in figure 1)</p>
|
|||
|
<p>Forcing everyone to rebuild the world every time there’s an alpha release in
|
|||
|
the rolling release stream would almost certainly lead to publishers deciding
|
|||
|
supporting the rolling releases was more trouble than it was worth, so we want
|
|||
|
to allow modules built against X.Y.0a1 to be loaded against X.Y.0a7, as they’re
|
|||
|
<em>probably</em> going to be compatible (there are very few projects that use every
|
|||
|
C API that CPython publishes, and most ABI breaks affect a single specific API).</p>
|
|||
|
<p>Once we publish X.Y.0rc1 though, we want to ensure that any binaries that were
|
|||
|
built against X.Y.0a1 and X.Y.0a4 are completely removed from the end user
|
|||
|
experience. It would be nice to be able to keep the builds against X.Y.0a7 and
|
|||
|
any subsequent beta releases (since it turned out those actually were built
|
|||
|
against the post-freeze ABI, even if we didn’t know that at the time), but
|
|||
|
losing them isn’t any <em>worse</em> than the status quo.</p>
|
|||
|
<p>This means that the pre-freeze flag is “the simplest thing that could possibly
|
|||
|
work” to solve this problem - it’s just a new ABI flag, and we already have
|
|||
|
the tools available to deal with ABI flags (both in the interpreter and in
|
|||
|
package publication and installation tools).</p>
|
|||
|
<p>Since the ABI flags have changed relative to the pre-releases, projects don’t
|
|||
|
even need to publish a new release: they can upload new wheel archives to their
|
|||
|
existing releases, just as they can today.</p>
|
|||
|
<p>A cleverer scheme that was able to retroactively accept everything built
|
|||
|
against the last alpha or subsequent beta releases would likely be possible,
|
|||
|
but it isn’t considered <em>necessary</em> for adoption of this PEP, as even if we
|
|||
|
initially start out with a simple pre-release ABI flag, it would still be
|
|||
|
possible to devise a more sophisticated approach in the future.</p>
|
|||
|
</section>
|
|||
|
<section id="why-allow-additional-alpha-releases-after-x-y-0a1">
|
|||
|
<h3><a class="toc-backref" href="#why-allow-additional-alpha-releases-after-x-y-0a1" role="doc-backlink">Why allow additional alpha releases after X.Y.0a1?</a></h3>
|
|||
|
<p>In an ideal world, all breaking changes to the full CPython ABI would land in
|
|||
|
X.Y.0a1 alongside the filesystem layout changes, and the ABI for the release
|
|||
|
series would remain stable after that.</p>
|
|||
|
<p>However, recent history doesn’t suggest that we’d be able to actually make that
|
|||
|
commitment and stick to it, so the PEP assumes that ABI changes will be made
|
|||
|
progressively throughout the pre-freeze period, and the full lockdown will occur
|
|||
|
only with the creation of the X.Y.z maintenance branch when preparing X.Y.0rc1.</p>
|
|||
|
</section>
|
|||
|
<section id="implications-for-cpython-core-development">
|
|||
|
<h3><a class="toc-backref" href="#implications-for-cpython-core-development" role="doc-backlink">Implications for CPython core development</a></h3>
|
|||
|
<p>The major change for CPython core development is the need to keep the master
|
|||
|
branch more consistently release ready.</p>
|
|||
|
<p>While the main requirement for that would be to keep the stable BuildBot fleet
|
|||
|
green, there would also be encouragement to keep the development version of
|
|||
|
the documentation up to date for the benefit of users of the rolling pre-freeze
|
|||
|
releases. This will include providing draft What’s New entries for changes as
|
|||
|
they are implemented, although the initial versions may be relatively sparse,
|
|||
|
and then expanded based on feedback from beta release users.</p>
|
|||
|
<p>For core developers working on the CPython C API, there would also be a new
|
|||
|
requirement to consistently mark ABI breaking changes in their NEWS file
|
|||
|
snippets.</p>
|
|||
|
<p>On the specific topic of the stable ABI, most API designs will be able to go
|
|||
|
through a process where they’re first introduced as a provisional part of the
|
|||
|
full CPython API (allowing changes between pre-freeze releases), and only
|
|||
|
promoted to the stable ABI once developers are confident that the interface
|
|||
|
is genuinely stable.</p>
|
|||
|
<p>It’s only in rare cases where an API serves no useful purpose outside the
|
|||
|
stable ABI that it may make sense to publish an alpha release containing a
|
|||
|
provisional stable ABI addition rather than iterating on the design in the
|
|||
|
provisional CPython API instead.</p>
|
|||
|
</section>
|
|||
|
<section id="implications-for-python-library-development">
|
|||
|
<h3><a class="toc-backref" href="#implications-for-python-library-development" role="doc-backlink">Implications for Python library development</a></h3>
|
|||
|
<p>If this PEP is successful in its aims, then supporting the rolling pre-freeze
|
|||
|
release stream shouldn’t be subtantially more painful for library authors than
|
|||
|
supporting the stable releases.</p>
|
|||
|
<p>For publishers of pure Python packages, this would be a matter of publishing
|
|||
|
“py3” tagged wheel archives, and potentially adding the rolling pre-freeze
|
|||
|
release stream to their test matrix if that option is available to them.</p>
|
|||
|
<p>For publishers of binary extension modules, the preferred option would be to
|
|||
|
target the stable C ABI (if feasible), and thus enjoy an experience similar to
|
|||
|
that of pure Python packages, where a single pre-built wheel archive is able to
|
|||
|
cover multiple versions of Python, including the rolling pre-freeze release
|
|||
|
stream.</p>
|
|||
|
<p>This option isn’t going to be viable for all libraries, and the desired outcome
|
|||
|
for those authors is that they be able to support the rolling releases by
|
|||
|
building and publishing one additional wheel archive, built against the initial
|
|||
|
X.Y.0a1 release. The subsequent build against X.Y.0rc1 or later is then the same
|
|||
|
build that would have been needed if only supporting the final stable release.</p>
|
|||
|
<p>Additional wheel builds beyond those two should then only be needed if that
|
|||
|
particular library is directly affected by an ABI break in any other alpha
|
|||
|
release that occurs between those two points.</p>
|
|||
|
<p>Having a rolling pre-freeze release stream available may also make it more feasible
|
|||
|
for more CI providers to offer a “CPython beta release” testing option. At the
|
|||
|
moment, this feature is only available from CI providers that are willing and
|
|||
|
able to put the necessary time and effort into creating, testing, and publishing
|
|||
|
their own builds from the CPython master branch (e.g. <a class="footnote-reference brackets" href="#id13" id="id6">[6]</a>).</p>
|
|||
|
</section>
|
|||
|
<section id="implications-for-the-proposed-scientific-python-ecosystem-support-period">
|
|||
|
<h3><a class="toc-backref" href="#implications-for-the-proposed-scientific-python-ecosystem-support-period" role="doc-backlink">Implications for the proposed Scientific Python ecosystem support period</a></h3>
|
|||
|
<p>Based on discussions at SciPy 2019, NEP (NumPy Enhancement Proposal) 29 has
|
|||
|
been drafted <a class="footnote-reference brackets" href="#id10" id="id7">[3]</a> to propose a common convention across the Scientific Python
|
|||
|
ecosystem for dropping support for older Python versions.</p>
|
|||
|
<p>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.</p>
|
|||
|
<p>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
|
|||
|
X.Y.Z releases around 6 months after X.(Y+2).0 is released. This means there is
|
|||
|
a 6-month period roughly every other year where the three most recent feature
|
|||
|
releases are supported.</p>
|
|||
|
<p>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,
|
|||
|
with the other half of each year hopefully being used to get ready for that
|
|||
|
year’s feature release.</p>
|
|||
|
<p>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.</p>
|
|||
|
</section>
|
|||
|
<section id="release-cycle-alignment-for-core-development-sprints">
|
|||
|
<h3><a class="toc-backref" href="#release-cycle-alignment-for-core-development-sprints" role="doc-backlink">Release cycle alignment for core development sprints</a></h3>
|
|||
|
<p>With the proposal in this PEP, it is expected that the focus of core
|
|||
|
development sprints would shift slightly based on the current location
|
|||
|
in the two-year cycle.</p>
|
|||
|
<p>In release years, the timing of PyCon US is suitable for new contributors to
|
|||
|
work on bug fixes and smaller features before the first release candidate goes
|
|||
|
out, while the Language Summit and core developer discussions can focus on
|
|||
|
plans for the next release series.</p>
|
|||
|
<p>The pre-alpha core development sprint in release years will provide an
|
|||
|
opportunity to incorporate feedback received on the previous release, either
|
|||
|
as part of the next maintenance release (for bug fixes and feedback on
|
|||
|
provisional APIs), or as part of the first alpha release of the next release
|
|||
|
series (for feedback received on stable APIs).</p>
|
|||
|
<p>Those initial alpha releases would also be the preferred target for ABI breaking
|
|||
|
changes to the full CPython ABI (while changes later in the release cycle
|
|||
|
would still be permitted as described in this PEP, landing them in the X.Y.0a1
|
|||
|
release means that they won’t trigger any additional work for publishers of
|
|||
|
pre-built binary packages).</p>
|
|||
|
<p>The Steering Council elections for the next release cycle are also likely to
|
|||
|
occur around the same time as the pre-alpha development sprints.</p>
|
|||
|
<p>In non-release years, the focus for both events would just be on the upcoming
|
|||
|
maintenance and pre-freeze releases. These less intense years would hopefully
|
|||
|
provide an opportunity to tackle various process changes and infrastructure
|
|||
|
upgrades without impacting the release candidate preparation process.</p>
|
|||
|
</section>
|
|||
|
<section id="release-cycle-alignment-for-prominent-linux-distributions">
|
|||
|
<h3><a class="toc-backref" href="#release-cycle-alignment-for-prominent-linux-distributions" role="doc-backlink">Release cycle alignment for prominent Linux distributions</a></h3>
|
|||
|
<p>Some rolling release Linux distributions (e.g. Arch, Gentoo) may be in a
|
|||
|
position to consume the new rolling pre-freeze releases proposed in this PEP,
|
|||
|
but it is expected that most distributions would continue to use the established
|
|||
|
releases.</p>
|
|||
|
<p>The specific dates for final releases proposed in this PEP are chosen to align
|
|||
|
with the feature freeze schedules for the annual October releases of the Ubuntu
|
|||
|
and Fedora Linux distributions.</p>
|
|||
|
<p>For both Fedora and Ubuntu, it means that the release candidate phase aligns
|
|||
|
with the development period for a distro release, which is the ideal time for
|
|||
|
them to test a new version and provide feedback on potential regressions and
|
|||
|
compatibility concerns.</p>
|
|||
|
<p>For Ubuntu, this also means that their April LTS releases will have benefited
|
|||
|
from a full short-term release cycle using the new system Python version, while
|
|||
|
still having that CPython release be open to upstream bug fixes for most of the
|
|||
|
time until the next Ubuntu LTS release.</p>
|
|||
|
<p>The one Linux release cycle alignment that is likely to be consistently poor
|
|||
|
with the specific proposal in this PEP is with Debian, as that has been released
|
|||
|
in the first half of odd-numbered years since 2005 (roughly 12 months offset
|
|||
|
from Ubuntu LTS releases).</p>
|
|||
|
<p>With the annual release proposal in <a class="pep reference internal" href="../pep-0602/" title="PEP 602 – Annual Release Cycle for Python">PEP 602</a>, both Debian and Ubuntu LTS would
|
|||
|
consistently get a system Python version that is around 6 months old, but
|
|||
|
would also consistently select different Python versions from each other.</p>
|
|||
|
<p>With a two-year cadence, and CPython releases in the latter half of the year,
|
|||
|
they’re likely to select the same version as each other, but one of them will
|
|||
|
be choosing a CPython release that is more than 18 months behind the latest beta
|
|||
|
releases by the time the Linux distribution ships.</p>
|
|||
|
<p>If that situation does occur, and is deemed undesirable (but not sufficiently
|
|||
|
undesirable for <em>Debian</em> to choose to adjust their release timing), then that’s
|
|||
|
where the additional complexity of the “incremental feature release” proposal
|
|||
|
in <a class="pep reference internal" href="../pep-0598/" title="PEP 598 – Introducing incremental feature releases">PEP 598</a> may prove worthwhile.</p>
|
|||
|
<p>(Moving CPython releases to the same half of the year as the Debian and Ubuntu
|
|||
|
LTS releases would potentially help mitigate the problem, but also creates
|
|||
|
new problems where a slip in the CPython release schedule could directly affect
|
|||
|
the release schedule for a Linux distribution, or else result in a distribution
|
|||
|
shipping a Python version that is <em>more</em> than 18 months old)</p>
|
|||
|
</section>
|
|||
|
<section id="implications-for-simple-deployment-environments">
|
|||
|
<h3><a class="toc-backref" href="#implications-for-simple-deployment-environments" role="doc-backlink">Implications for simple deployment environments</a></h3>
|
|||
|
<p>For the purposes of this PEP, a “simple” deployment environment is any use case
|
|||
|
where it is straightforward to ensure that all target environments are updated
|
|||
|
to a new Python release at the same time (or at least in advance of the rollout
|
|||
|
of new higher level application versions), and any pre-release testing that
|
|||
|
occurs need only target a single Python micro version.</p>
|
|||
|
<p>The simplest such case would be scripting for personal use, where the testing
|
|||
|
and target environments are the exact same environment.</p>
|
|||
|
<p>Similarly simple environments would be containerised web services, where the
|
|||
|
same Python container is used in the CI pipeline as is used on deployment, and
|
|||
|
any application that bundles its own Python runtime, rather than relying on a
|
|||
|
pre-existing Python deployment on the target system.</p>
|
|||
|
<p>For these use cases, there is a straightforward mechanism to minimise the
|
|||
|
impact of this PEP: continue using the stable releases, and ignore the rolling
|
|||
|
pre-freeze releases.</p>
|
|||
|
<p>To actually adopt the rolling pre-freeze releases in these environments, the
|
|||
|
main challenge will be handling the potential for extension module segfaults
|
|||
|
when the next pre-freeze release is an alpha release rather than a beta
|
|||
|
release, indicating that the CPython ABI may have changed in an incompatible
|
|||
|
way.</p>
|
|||
|
<p>If all extension modules in use target the stable ABI, then there’s no problem,
|
|||
|
and everything will work just as smoothly as it does on the stable releases.</p>
|
|||
|
<p>Alternatively, “rebuild and recache all extension modules” could become a
|
|||
|
standard activity undertaken as part of updating to an alpha release.</p>
|
|||
|
<p>Finally, it would also be reasonable to just not worry about it until something
|
|||
|
actually breaks, and then handle it like any other library compatibility issue
|
|||
|
found in a new alpha or beta release.</p>
|
|||
|
<p>Aside from extension module ABI compatibility, the other main point of additional
|
|||
|
complexity when using the rolling pre-freeze releases would be “roll-back”
|
|||
|
compatibility for independently versioned features, such as pickle and SQLite,
|
|||
|
where use of new or provisional features in the beta stream may create files
|
|||
|
that are not readable by the stable release. Applications that use these
|
|||
|
kinds of features and also require the ability to reliably roll-back to a
|
|||
|
previous stable CPython release would, as today, be advised to avoid adopting
|
|||
|
pre-release versions.</p>
|
|||
|
</section>
|
|||
|
<section id="implications-for-complex-deployment-environments">
|
|||
|
<h3><a class="toc-backref" href="#implications-for-complex-deployment-environments" role="doc-backlink">Implications for complex deployment environments</a></h3>
|
|||
|
<p>For the purposes of this PEP, “complex” deployment environments are use cases
|
|||
|
which don’t meet the “simple deployment” criteria above. They may involve
|
|||
|
multiple distinct versions of Python, use of a personalised build of Python,
|
|||
|
or “gatekeepers” who are required to approve use of a new version prior to
|
|||
|
deployment.</p>
|
|||
|
<p>For example, organisations that install Python on their users’ machines as part
|
|||
|
of a standard operating environment fall into this category, as do those that
|
|||
|
provide a standard build environment. Distributions such as conda-forge or
|
|||
|
WinPython that provide collections of consistently built and verified packages
|
|||
|
are impacted in similar ways.</p>
|
|||
|
<p>These organisations tend to either prefer high stability (for example, all of
|
|||
|
those who are happily using the system Python in a stable Linux distribution
|
|||
|
like Debian, RHEL/CentOS, or Ubuntu LTS as their preferred Python environment)
|
|||
|
or fast turnaround (for example, those who regularly contribute toward the
|
|||
|
latest CPython pre-releases).</p>
|
|||
|
<p>In some cases, both usage models may exist within the same organisation for
|
|||
|
different purposes, such as:</p>
|
|||
|
<ul class="simple">
|
|||
|
<li>using a stable Python environment for mission critical systems, but allowing
|
|||
|
data scientists to use the latest available version for ad hoc data analysis</li>
|
|||
|
<li>a hardware manufacturer deploying a stable Python version as part of their
|
|||
|
production firmware, but using the latest available version in the development
|
|||
|
and execution of their automated integration tests</li>
|
|||
|
</ul>
|
|||
|
<p>Under any release model, each new release of Python generates work for these
|
|||
|
organisations. This work may involve legal, security or technical reviews of
|
|||
|
Python itself, assessment and verification of impactful changes, reapplication
|
|||
|
of patches, recompilation and testing of third-party dependencies, and
|
|||
|
only then deployment.</p>
|
|||
|
<p>Organisations that can take updates quickly should be able to make use of the
|
|||
|
more frequent beta releases. While each update will still require similar
|
|||
|
investigative work to what they require today, the volume of work required per
|
|||
|
release should be reduced as each release will be more similar to the previous
|
|||
|
than it is under the present model. One advantage of the proposed
|
|||
|
release-every-2-months model is that organisations can choose their own adoption
|
|||
|
cadence from adopting every beta release, to adopting one per quarter, or one
|
|||
|
every 6 months, or one every year. Beyond that, it would likely make more sense
|
|||
|
to continue using the stable releases instead.</p>
|
|||
|
<p>For organisations with stricter evaluations or a preference for stability, the
|
|||
|
longer release cycle for stable releases will reduce the annual effort required
|
|||
|
to update, the longer release candidate period will allow more time to do
|
|||
|
internal testing before the X.Y.0 release, and the greater use by others
|
|||
|
during the beta period will provide more confidence in the initial releases.
|
|||
|
Meanwhile, the organisation can confidently upgrade through maintenance
|
|||
|
releases for a longer time without fear of breaking changes.</p>
|
|||
|
</section>
|
|||
|
</section>
|
|||
|
<section id="acknowledgements">
|
|||
|
<h2><a class="toc-backref" href="#acknowledgements" role="doc-backlink">Acknowledgements</a></h2>
|
|||
|
<p>Thanks to Łukasz Langa for creating <a class="pep reference internal" href="../pep-0602/" title="PEP 602 – Annual Release Cycle for Python">PEP 602</a> and prompting this discussion of
|
|||
|
possible improvements to the CPython release cadence, and to Kyle Stanley
|
|||
|
and h-vetinari for constructive feedback on the initial draft of this PEP.</p>
|
|||
|
</section>
|
|||
|
<section id="references">
|
|||
|
<h2><a class="toc-backref" href="#references" role="doc-backlink">References</a></h2>
|
|||
|
<aside class="footnote-list brackets">
|
|||
|
<aside class="footnote brackets" id="id8" role="doc-footnote">
|
|||
|
<dt class="label" id="id8">[<a href="#id4">1</a>]</dt>
|
|||
|
<dd>Steve Dower’s initial “Fast and Stable releases” proposal
|
|||
|
(<a class="reference external" href="https://discuss.python.org/t/pep-602-annual-release-cycle-for-python/2296/20">https://discuss.python.org/t/pep-602-annual-release-cycle-for-python/2296/20</a>)</aside>
|
|||
|
<aside class="footnote brackets" id="id9" role="doc-footnote">
|
|||
|
<dt class="label" id="id9">[<a href="#id5">2</a>]</dt>
|
|||
|
<dd>Paul Moore’s initial comments on Steve’s proposal
|
|||
|
(<a class="reference external" href="https://discuss.python.org/t/pep-602-annual-release-cycle-for-python/2296/37">https://discuss.python.org/t/pep-602-annual-release-cycle-for-python/2296/37</a>)</aside>
|
|||
|
<aside class="footnote brackets" id="id10" role="doc-footnote">
|
|||
|
<dt class="label" id="id10">[<a href="#id7">3</a>]</dt>
|
|||
|
<dd>NEP 29 proposes a common policy for dropping support of old Python versions
|
|||
|
(<a class="reference external" href="https://numpy.org/neps/nep-0029-deprecation_policy.html">https://numpy.org/neps/nep-0029-deprecation_policy.html</a>)</aside>
|
|||
|
<aside class="footnote brackets" id="id11" role="doc-footnote">
|
|||
|
<dt class="label" id="id11">[<a href="#id3">4</a>]</dt>
|
|||
|
<dd>Example implementation for a pre-release SOABI flag
|
|||
|
(<a class="reference external" href="https://github.com/ncoghlan/cpython/pull/3">https://github.com/ncoghlan/cpython/pull/3</a>)</aside>
|
|||
|
<aside class="footnote brackets" id="id12" role="doc-footnote">
|
|||
|
<dt class="label" id="id12">[<a href="#id2">5</a>]</dt>
|
|||
|
<dd>CPython stable ABI documentation
|
|||
|
(<a class="reference external" href="https://docs.python.org/3/c-api/stable.html">https://docs.python.org/3/c-api/stable.html</a>)</aside>
|
|||
|
<aside class="footnote brackets" id="id13" role="doc-footnote">
|
|||
|
<dt class="label" id="id13">[<a href="#id6">6</a>]</dt>
|
|||
|
<dd>Travis CI nightly CPython builds
|
|||
|
(<a class="reference external" href="https://docs.travis-ci.com/user/languages/python/#nightly-build-support">https://docs.travis-ci.com/user/languages/python/#nightly-build-support</a>)</aside>
|
|||
|
</aside>
|
|||
|
</section>
|
|||
|
<section id="copyright">
|
|||
|
<h2><a class="toc-backref" href="#copyright" role="doc-backlink">Copyright</a></h2>
|
|||
|
<p>This document is placed in the public domain or under the CC0-1.0-Universal
|
|||
|
license, whichever is more permissive.</p>
|
|||
|
</section>
|
|||
|
</section>
|
|||
|
<hr class="docutils" />
|
|||
|
<p>Source: <a class="reference external" href="https://github.com/python/peps/blob/main/peps/pep-0605.rst">https://github.com/python/peps/blob/main/peps/pep-0605.rst</a></p>
|
|||
|
<p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0605.rst">2023-10-11 12:05:51 GMT</a></p>
|
|||
|
|
|||
|
</article>
|
|||
|
<nav id="pep-sidebar">
|
|||
|
<h2>Contents</h2>
|
|||
|
<ul>
|
|||
|
<li><a class="reference internal" href="#rejection-notice">Rejection Notice</a></li>
|
|||
|
<li><a class="reference internal" href="#abstract">Abstract</a></li>
|
|||
|
<li><a class="reference internal" href="#example-future-release-schedules">Example Future Release Schedules</a></li>
|
|||
|
<li><a class="reference internal" href="#example-future-release-announcements">Example Future Release Announcements</a><ul>
|
|||
|
<li><a class="reference internal" href="#suggested-what-s-new-in-python-3-9-entry">Suggested “What’s New in Python 3.9” Entry</a><ul>
|
|||
|
<li><a class="reference internal" href="#pep-605-changes-to-the-pre-release-management-process">PEP 605: Changes to the pre-release management process</a></li>
|
|||
|
</ul>
|
|||
|
</li>
|
|||
|
<li><a class="reference internal" href="#example-announcement-text-for-the-3-9-0a1-release">Example announcement text for the 3.9.0a1 release</a><ul>
|
|||
|
<li><a class="reference internal" href="#changes-to-the-pre-release-management-process">Changes to the pre-release management process</a></li>
|
|||
|
<li><a class="reference internal" href="#major-new-features-of-the-3-9-series-compared-to-3-8">Major new features of the 3.9 series, compared to 3.8</a></li>
|
|||
|
</ul>
|
|||
|
</li>
|
|||
|
<li><a class="reference internal" href="#example-announcement-text-for-the-3-9-0b2-release">Example announcement text for the 3.9.0b2 release</a></li>
|
|||
|
<li><a class="reference internal" href="#example-announcement-text-for-3-9-0a5-a-mid-stream-alpha-release">Example announcement text for 3.9.0a5 (a mid-stream alpha release)</a><ul>
|
|||
|
<li><a class="reference internal" href="#breaking-changes-in-the-full-cpython-abi-between-3-9-0b4-and-3-9-0a5">Breaking changes in the full CPython ABI between 3.9.0b4 and 3.9.0a5</a></li>
|
|||
|
</ul>
|
|||
|
</li>
|
|||
|
<li><a class="reference internal" href="#example-announcement-text-for-3-9-0rc1">Example announcement text for 3.9.0rc1</a><ul>
|
|||
|
<li><a class="reference internal" href="#preparation-for-the-final-3-9-0-release">Preparation for the final 3.9.0 release</a></li>
|
|||
|
<li><a class="reference internal" href="#id1">Major new features of the 3.9 series, compared to 3.8</a></li>
|
|||
|
</ul>
|
|||
|
</li>
|
|||
|
</ul>
|
|||
|
</li>
|
|||
|
<li><a class="reference internal" href="#motivation">Motivation</a></li>
|
|||
|
<li><a class="reference internal" href="#aims-of-this-proposal">Aims of this Proposal</a></li>
|
|||
|
<li><a class="reference internal" href="#proposal">Proposal</a><ul>
|
|||
|
<li><a class="reference internal" href="#two-year-cadence-for-stable-releases">Two year cadence for stable releases</a></li>
|
|||
|
<li><a class="reference internal" href="#merging-of-the-alpha-and-beta-phases-into-a-pre-freeze-phase">Merging of the alpha and beta phases into a “pre-freeze” phase</a><ul>
|
|||
|
<li><a class="reference internal" href="#pre-freeze-phase-duration-and-cadence">Pre-freeze phase duration and cadence</a></li>
|
|||
|
<li><a class="reference internal" href="#release-policy-for-beta-releases">Release policy for beta releases</a></li>
|
|||
|
<li><a class="reference internal" href="#release-policy-for-alpha-releases">Release policy for alpha releases</a></li>
|
|||
|
</ul>
|
|||
|
</li>
|
|||
|
<li><a class="reference internal" href="#release-candidate-policy-phase-duration-and-cadence">Release candidate policy, phase duration, and cadence</a></li>
|
|||
|
<li><a class="reference internal" href="#changes-to-management-of-the-cpython-stable-c-abi">Changes to management of the CPython stable C ABI</a></li>
|
|||
|
<li><a class="reference internal" href="#changes-to-management-of-the-full-cpython-abi">Changes to management of the full CPython ABI</a><ul>
|
|||
|
<li><a class="reference internal" href="#an-explicit-commit-and-news-file-convention-to-mark-abi-breaking-changes">An explicit commit and NEWS file convention to mark ABI breaking changes</a></li>
|
|||
|
<li><a class="reference internal" href="#explicitly-marking-builds-against-the-pre-freeze-abi">Explicitly marking builds against the pre-freeze ABI</a></li>
|
|||
|
</ul>
|
|||
|
</li>
|
|||
|
<li><a class="reference internal" href="#updating-python-requires-for-projects-affected-by-full-c-abi-changes">Updating Python-Requires for projects affected by full C ABI changes</a></li>
|
|||
|
</ul>
|
|||
|
</li>
|
|||
|
<li><a class="reference internal" href="#caveats-and-limitations">Caveats and Limitations</a></li>
|
|||
|
<li><a class="reference internal" href="#design-discussion">Design Discussion</a><ul>
|
|||
|
<li><a class="reference internal" href="#why-rolling-pre-freeze-releases-over-simply-doing-more-frequent-x-y-0-releases">Why rolling pre-freeze releases over simply doing more frequent X.Y.0 releases?</a></li>
|
|||
|
<li><a class="reference internal" href="#is-it-necessary-to-keep-the-alpha-and-beta-naming-scheme">Is it necessary to keep the “alpha” and “beta” naming scheme?</a></li>
|
|||
|
<li><a class="reference internal" href="#why-rolling-pre-freeze-releases-rather-than-alternating-between-stable-and-unstable-release-series">Why rolling pre-freeze releases rather than alternating between stable and unstable release series?</a></li>
|
|||
|
<li><a class="reference internal" href="#why-not-use-calendar-versioning-for-the-rolling-release-stream">Why not use Calendar Versioning for the rolling release stream?</a></li>
|
|||
|
<li><a class="reference internal" href="#how-would-users-of-the-rolling-pre-freeze-releases-detect-api-changes">How would users of the rolling pre-freeze releases detect API changes?</a></li>
|
|||
|
<li><a class="reference internal" href="#why-add-a-new-pre-freeze-abi-flag-to-force-rebuilds-after-x-y-0rc1">Why add a new pre-freeze ABI flag to force rebuilds after X.Y.0rc1?</a></li>
|
|||
|
<li><a class="reference internal" href="#why-allow-additional-alpha-releases-after-x-y-0a1">Why allow additional alpha releases after X.Y.0a1?</a></li>
|
|||
|
<li><a class="reference internal" href="#implications-for-cpython-core-development">Implications for CPython core development</a></li>
|
|||
|
<li><a class="reference internal" href="#implications-for-python-library-development">Implications for Python library development</a></li>
|
|||
|
<li><a class="reference internal" href="#implications-for-the-proposed-scientific-python-ecosystem-support-period">Implications for the proposed Scientific Python ecosystem support period</a></li>
|
|||
|
<li><a class="reference internal" href="#release-cycle-alignment-for-core-development-sprints">Release cycle alignment for core development sprints</a></li>
|
|||
|
<li><a class="reference internal" href="#release-cycle-alignment-for-prominent-linux-distributions">Release cycle alignment for prominent Linux distributions</a></li>
|
|||
|
<li><a class="reference internal" href="#implications-for-simple-deployment-environments">Implications for simple deployment environments</a></li>
|
|||
|
<li><a class="reference internal" href="#implications-for-complex-deployment-environments">Implications for complex deployment environments</a></li>
|
|||
|
</ul>
|
|||
|
</li>
|
|||
|
<li><a class="reference internal" href="#acknowledgements">Acknowledgements</a></li>
|
|||
|
<li><a class="reference internal" href="#references">References</a></li>
|
|||
|
<li><a class="reference internal" href="#copyright">Copyright</a></li>
|
|||
|
</ul>
|
|||
|
|
|||
|
<br>
|
|||
|
<a id="source" href="https://github.com/python/peps/blob/main/peps/pep-0605.rst">Page Source (GitHub)</a>
|
|||
|
</nav>
|
|||
|
</section>
|
|||
|
<script src="../_static/colour_scheme.js"></script>
|
|||
|
<script src="../_static/wrap_tables.js"></script>
|
|||
|
<script src="../_static/sticky_banner.js"></script>
|
|||
|
</body>
|
|||
|
</html>
|