mirror of https://github.com/python/peps
314 lines
23 KiB
HTML
314 lines
23 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 607 – Reducing CPython’s Feature Delivery Latency | peps.python.org</title>
|
||
<link rel="shortcut icon" href="../_static/py.png">
|
||
<link rel="canonical" href="https://peps.python.org/pep-0607/">
|
||
<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 607 – Reducing CPython’s Feature Delivery Latency | peps.python.org'>
|
||
<meta property="og:type" content="website">
|
||
<meta property="og:url" content="https://peps.python.org/pep-0607/">
|
||
<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="Python Enhancement Proposals (PEPs)">
|
||
<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 607</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 607 – Reducing CPython’s Feature Delivery Latency</h1>
|
||
<dl class="rfc2822 field-list simple">
|
||
<dt class="field-odd">Author<span class="colon">:</span></dt>
|
||
<dd class="field-odd">Łukasz Langa <lukasz at python.org>,
|
||
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-607-shared-background-for-the-release-cadence-peps/2528">Discourse thread</a></dd>
|
||
<dt class="field-odd">Status<span class="colon">:</span></dt>
|
||
<dd class="field-odd"><abbr title="Accepted and implementation complete, or no longer active">Final</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">11-Oct-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">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="#abstract">Abstract</a></li>
|
||
<li><a class="reference internal" href="#rationale-for-change">Rationale for change</a><ul>
|
||
<li><a class="reference internal" href="#reducing-the-size-of-feature-delivery-batches">Reducing the size of feature delivery batches</a></li>
|
||
<li><a class="reference internal" href="#reducing-the-latency-of-feature-delivery">Reducing the latency of feature delivery</a></li>
|
||
<li><a class="reference internal" href="#aligning-the-release-cadence-with-the-calendar-year">Aligning the release cadence with the calendar year</a></li>
|
||
<li><a class="reference internal" href="#improving-the-pre-release-design-feedback-cycle">Improving the pre-release design feedback cycle</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#risks-to-be-mitigated">Risks to be mitigated</a><ul>
|
||
<li><a class="reference internal" href="#impact-on-users-and-redistributors-that-already-skip-some-releases">Impact on users and redistributors that already skip some releases</a></li>
|
||
<li><a class="reference internal" href="#impact-on-users-and-redistributors-that-update-to-every-release">Impact on users and redistributors that update to every release</a></li>
|
||
<li><a class="reference internal" href="#impact-on-users-and-redistributors-of-cpython-nightly-builds">Impact on users and redistributors of CPython nightly builds</a></li>
|
||
<li><a class="reference internal" href="#impact-on-maintainers-of-third-party-libraries">Impact on maintainers of third party libraries</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#copyright">Copyright</a></li>
|
||
</ul>
|
||
</details></section>
|
||
<section id="abstract">
|
||
<h2><a class="toc-backref" href="#abstract" role="doc-backlink">Abstract</a></h2>
|
||
<p><a class="pep reference internal" href="../pep-0602/" title="PEP 602 – Annual Release Cycle for Python">PEP 602</a> and <a class="pep reference internal" href="../pep-0605/" title="PEP 605 – A rolling feature release stream for CPython">PEP 605</a> describe two alternative approaches to delivering smaller
|
||
collections of features to Python’s users more frequently (as compared to the
|
||
current approach of offering new feature releases every 18-24 months, with
|
||
the first binary alpha release taking place 6-8 months before the final release).</p>
|
||
<p>Both PEPs also propose moving to a release cadence that results in full releases
|
||
occurring at a consistent time of year (every year for <a class="pep reference internal" href="../pep-0602/" title="PEP 602 – Annual Release Cycle for Python">PEP 602</a>, every other
|
||
year for <a class="pep reference internal" href="../pep-0605/" title="PEP 605 – A rolling feature release stream for CPython">PEP 605</a>).</p>
|
||
<p>This PEP (from the authors of both competing proposals) provides common
|
||
background on <em>why</em> a change in the release cadence is considered desirable,
|
||
as well as the perceived risks that both PEPs attempt to mitigate.</p>
|
||
</section>
|
||
<section id="rationale-for-change">
|
||
<h2><a class="toc-backref" href="#rationale-for-change" role="doc-backlink">Rationale for change</a></h2>
|
||
<section id="reducing-the-size-of-feature-delivery-batches">
|
||
<h3><a class="toc-backref" href="#reducing-the-size-of-feature-delivery-batches" role="doc-backlink">Reducing the size of feature delivery batches</a></h3>
|
||
<p>When multiple large changes are delivered together, a complex investigation
|
||
may be required to determine the root cause of any new issues that arise.
|
||
Large batch sizes also make it more likely that problems <em>will</em> be encountered,
|
||
given that they include larger pieces of relatively untested code.</p>
|
||
<p>The easiest way to simplify those investigations and reduce the likelihood of
|
||
users encountering problems is to reduce the size of the batches being shipped.</p>
|
||
<p><a class="pep reference internal" href="../pep-0602/" title="PEP 602 – Annual Release Cycle for Python">PEP 602</a> proposes to address this problem via the straightforward approach of
|
||
reducing CPython’s typical batch size by 50%, shipping 12 months of changes
|
||
each time, rather than accumulating 18+ months of changes.</p>
|
||
<p><a class="pep reference internal" href="../pep-0605/" title="PEP 605 – A rolling feature release stream for CPython">PEP 605</a> proposes to address it by regularly delivering 2 months worth of changes
|
||
to a subset of Python’s user base that opts in to running a rolling stream of
|
||
beta releases (similar to running Windows Insider builds instead of the Windows
|
||
retail release, or running Debian testing instead of Debian stable).</p>
|
||
</section>
|
||
<section id="reducing-the-latency-of-feature-delivery">
|
||
<h3><a class="toc-backref" href="#reducing-the-latency-of-feature-delivery" role="doc-backlink">Reducing the latency of feature delivery</a></h3>
|
||
<p>When only stable releases are seeing significant user adoption, and there’s a
|
||
long period of time between stable releases, it creates an incredibly strong
|
||
temptation for developers to push changes into stable releases before they’re
|
||
really ready for general use.</p>
|
||
<p><a class="pep reference internal" href="../pep-0602/" title="PEP 602 – Annual Release Cycle for Python">PEP 602</a> proposes to address this problem by reducing the period of time
|
||
between stable releases to 12 months rather than 18 months.</p>
|
||
<p><a class="pep reference internal" href="../pep-0605/" title="PEP 605 – A rolling feature release stream for CPython">PEP 605</a> proposes to address it by actively creating a community of
|
||
Python users that regularly install and use CPython beta releases, providing an
|
||
incentive for core developers to start shipping changes earlier in the
|
||
pre-release cycle, in order to obtain feedback before the feature gets locked
|
||
down in a stable release.</p>
|
||
</section>
|
||
<section id="aligning-the-release-cadence-with-the-calendar-year">
|
||
<h3><a class="toc-backref" href="#aligning-the-release-cadence-with-the-calendar-year" role="doc-backlink">Aligning the release cadence with the calendar year</a></h3>
|
||
<p>While the current release cadence is nominally 18-24 months, in practice it has
|
||
consistently been towards the 18 month end of that range. This means that the
|
||
target dates for pre-releases and final releases move around from release to
|
||
release, and the only way to remember them is to either look at the release PEP,
|
||
or else to add those dates to your calendar. This is annoying for both
|
||
individual volunteers and for corporate contributors, and also complicates
|
||
alignment with events like PyCon US (typically April/May) and the now-annual
|
||
core development sprints (typically in September).</p>
|
||
<p><a class="pep reference internal" href="../pep-0602/" title="PEP 602 – Annual Release Cycle for Python">PEP 602</a> proposes to address this problem by publishing a new release in October
|
||
every year, and basing the pre-release calendar for each year off that.</p>
|
||
<p><a class="pep reference internal" href="../pep-0605/" title="PEP 605 – A rolling feature release stream for CPython">PEP 605</a> proposes to address this problem by alternating between release years
|
||
(where a new stable release is published in August), and non-release years
|
||
(where only maintenance releases and new rolling beta releases are published).</p>
|
||
</section>
|
||
<section id="improving-the-pre-release-design-feedback-cycle">
|
||
<h3><a class="toc-backref" href="#improving-the-pre-release-design-feedback-cycle" role="doc-backlink">Improving the pre-release design feedback cycle</a></h3>
|
||
<p>One of the challenges of designing changes to the core interpreter and standard
|
||
library APIs is that the user base in a position to provide feedback on
|
||
nightly builds and the current pre-releases is relatively limited. This means
|
||
that much user feedback isn’t received until after an API design has already
|
||
shipped in a full X.Y.0 release.</p>
|
||
<p>If the API is a regular API, then deprecation cycles mean that it may take
|
||
literally years to correct any design mistakes identified at that point.
|
||
Marking APIs as provisional nominally offers a way to avoid that constraint,
|
||
but actually taking advantage of that freedom causes other problems.</p>
|
||
<p><a class="pep reference internal" href="../pep-0602/" title="PEP 602 – Annual Release Cycle for Python">PEP 602</a> proposes to address this problem by starting the alpha period
|
||
immediately after the previous stable release.</p>
|
||
<p><a class="pep reference internal" href="../pep-0605/" title="PEP 605 – A rolling feature release stream for CPython">PEP 605</a> proposes to address this problem by actively promoting adoption of
|
||
CPython pre-releases for running production workloads (not just for library and
|
||
application compatibility testing), and adjusting the pre-release management
|
||
process as necessary to make that a reasonable thing to do.</p>
|
||
<p>(Note: some standard library APIs are amenable to initially being shipped as
|
||
part of separately versioned packages via PyPI, and only later incorporated
|
||
into the standard library. This section is more about the lower level APIs
|
||
and non-library features where that approach to obtaining early design
|
||
feedback doesn’t apply)</p>
|
||
</section>
|
||
</section>
|
||
<section id="risks-to-be-mitigated">
|
||
<h2><a class="toc-backref" href="#risks-to-be-mitigated" role="doc-backlink">Risks to be mitigated</a></h2>
|
||
<p>While the status quo could stand to be improved in some respects, Python’s
|
||
popularity indicates that a lot of users and other participants in the wider
|
||
Python ecosystem are happy enough with the current release management process.</p>
|
||
<p>Python’s user base is too large and
|
||
<a class="reference external" href="https://www.curiousefficiency.org/posts/2017/10/considering-pythons-target-audience.html">too varied</a>
|
||
to cover all the potential downsides of changing our release cadence here, so
|
||
instead this section just covers some of the points that have been specifically
|
||
taken into account in the design of the PEPs.</p>
|
||
<section id="impact-on-users-and-redistributors-that-already-skip-some-releases">
|
||
<h3><a class="toc-backref" href="#impact-on-users-and-redistributors-that-already-skip-some-releases" role="doc-backlink">Impact on users and redistributors that already skip some releases</a></h3>
|
||
<p>It is already the case that not all users and redistributors update to every
|
||
published CPython release series (for example, Debian stable and Ubuntu LTS
|
||
sometimes skip releases due to the mismatch between their 24-month release
|
||
cycles and CPython’s typically 18-month cycle).</p>
|
||
<p>The faster 12-month full release cadence in <a class="pep reference internal" href="../pep-0602/" title="PEP 602 – Annual Release Cycle for Python">PEP 602</a> means that users in this
|
||
category may end up skipping two releases where they would previously have only
|
||
skipped one. However, the extended notice period for deprecations means that
|
||
skipping a single release should no longer result in missed deprecation warnings.</p>
|
||
<p>The slower 24-month full release cadence in <a class="pep reference internal" href="../pep-0605/" title="PEP 605 – A rolling feature release stream for CPython">PEP 605</a> may move some of the users
|
||
that have historically been in this category into the “update to every stable
|
||
release” category.</p>
|
||
</section>
|
||
<section id="impact-on-users-and-redistributors-that-update-to-every-release">
|
||
<h3><a class="toc-backref" href="#impact-on-users-and-redistributors-that-update-to-every-release" role="doc-backlink">Impact on users and redistributors that update to every release</a></h3>
|
||
<p>Many of Python’s users never install a pre-release, but do update to every
|
||
stable release series at some point after it is published.</p>
|
||
<p><a class="pep reference internal" href="../pep-0602/" title="PEP 602 – Annual Release Cycle for Python">PEP 602</a> aims to mitigate the potential negative impact on members of this group
|
||
by keeping the minimum gap between releases to 12 months, and retaining the
|
||
18 month full support period for each release.</p>
|
||
<p>Keeping the 18-month full support period for each release branch means that the
|
||
branches will spend roughly the same amount of time in full support and
|
||
security-fix-only mode as they do now (~18 months and ~42 months, respectively).</p>
|
||
<p><a class="pep reference internal" href="../pep-0605/" title="PEP 605 – A rolling feature release stream for CPython">PEP 605</a> aims to mitigate the potential negative impact on members of this group
|
||
by increasing use during the pre-release period to achieve more stable final
|
||
releases with wider ecosystem support at launch.</p>
|
||
<p>With a 24-month release cadence each release branch will spend proportionally
|
||
more time in full support mode and less time in security-fix-only mode
|
||
(~24 months and ~36 months, respectively).</p>
|
||
<p>Full discussion of the impact on this group is left to the individual PEPs.</p>
|
||
</section>
|
||
<section id="impact-on-users-and-redistributors-of-cpython-nightly-builds">
|
||
<h3><a class="toc-backref" href="#impact-on-users-and-redistributors-of-cpython-nightly-builds" role="doc-backlink">Impact on users and redistributors of CPython nightly builds</a></h3>
|
||
<p>Despite the difficulties of doing so, there are already some users and
|
||
redistributors that take on the challenge of using or publishing the CPython
|
||
master branch directly.</p>
|
||
<p>Neither <a class="pep reference internal" href="../pep-0602/" title="PEP 602 – Annual Release Cycle for Python">PEP 602</a> nor <a class="pep reference internal" href="../pep-0605/" title="PEP 605 – A rolling feature release stream for CPython">PEP 605</a> should directly affect this group, but the rolling
|
||
release stream proposal in <a class="pep reference internal" href="../pep-0605/" title="PEP 605 – A rolling feature release stream for CPython">PEP 605</a> aims to lower the barriers to more users
|
||
adopting this style of usage, by allowing them to adopt the tested rolling
|
||
beta stream, rather than needing to use the master branch directly.</p>
|
||
</section>
|
||
<section id="impact-on-maintainers-of-third-party-libraries">
|
||
<h3><a class="toc-backref" href="#impact-on-maintainers-of-third-party-libraries" role="doc-backlink">Impact on maintainers of third party libraries</a></h3>
|
||
<p>For maintainers of third party libraries, the key source of support complexity
|
||
is the <em>number</em> of different Python versions in widespread use.</p>
|
||
<p><a class="pep reference internal" href="../pep-0602/" title="PEP 602 – Annual Release Cycle for Python">PEP 602</a> aims to mitigate the potential negative impact on members of this group
|
||
by keeping the minimum gap between full releases to 12 months.</p>
|
||
<p><a class="pep reference internal" href="../pep-0605/" title="PEP 605 – A rolling feature release stream for CPython">PEP 605</a> aims to mitigate the potential negative impact on members of this group
|
||
by increasing the gap between full releases to 24 months, retaining the current
|
||
policy of moving each release branch to security-fix-only mode not long after
|
||
its successor is released, and retaining the “beta” naming scheme for the new
|
||
rolling release stream (at least for the Python 3.9 release cycle).</p>
|
||
<p>Full discussion of the impact on this group is left to the individual PEPs.</p>
|
||
</section>
|
||
</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-0607.rst">https://github.com/python/peps/blob/main/peps/pep-0607.rst</a></p>
|
||
<p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0607.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="#abstract">Abstract</a></li>
|
||
<li><a class="reference internal" href="#rationale-for-change">Rationale for change</a><ul>
|
||
<li><a class="reference internal" href="#reducing-the-size-of-feature-delivery-batches">Reducing the size of feature delivery batches</a></li>
|
||
<li><a class="reference internal" href="#reducing-the-latency-of-feature-delivery">Reducing the latency of feature delivery</a></li>
|
||
<li><a class="reference internal" href="#aligning-the-release-cadence-with-the-calendar-year">Aligning the release cadence with the calendar year</a></li>
|
||
<li><a class="reference internal" href="#improving-the-pre-release-design-feedback-cycle">Improving the pre-release design feedback cycle</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#risks-to-be-mitigated">Risks to be mitigated</a><ul>
|
||
<li><a class="reference internal" href="#impact-on-users-and-redistributors-that-already-skip-some-releases">Impact on users and redistributors that already skip some releases</a></li>
|
||
<li><a class="reference internal" href="#impact-on-users-and-redistributors-that-update-to-every-release">Impact on users and redistributors that update to every release</a></li>
|
||
<li><a class="reference internal" href="#impact-on-users-and-redistributors-of-cpython-nightly-builds">Impact on users and redistributors of CPython nightly builds</a></li>
|
||
<li><a class="reference internal" href="#impact-on-maintainers-of-third-party-libraries">Impact on maintainers of third party libraries</a></li>
|
||
</ul>
|
||
</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-0607.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> |