278 lines
16 KiB
HTML
278 lines
16 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 407 – New release cycle and introducing long-term support versions | peps.python.org</title>
|
||
<link rel="shortcut icon" href="../_static/py.png">
|
||
<link rel="canonical" href="https://peps.python.org/pep-0407/">
|
||
<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 407 – New release cycle and introducing long-term support versions | peps.python.org'>
|
||
<meta property="og:description" content="Finding a release cycle for an open-source project is a delicate exercise in managing mutually contradicting constraints: developer manpower, availability of release management volunteers, ease of maintenance for users and third-party packagers, quick a...">
|
||
<meta property="og:type" content="website">
|
||
<meta property="og:url" content="https://peps.python.org/pep-0407/">
|
||
<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="Finding a release cycle for an open-source project is a delicate exercise in managing mutually contradicting constraints: developer manpower, availability of release management volunteers, ease of maintenance for users and third-party packagers, quick a...">
|
||
<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 407</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 407 – New release cycle and introducing long-term support versions</h1>
|
||
<dl class="rfc2822 field-list simple">
|
||
<dt class="field-odd">Author<span class="colon">:</span></dt>
|
||
<dd class="field-odd">Antoine Pitrou <solipsis at pitrou.net>,
|
||
Georg Brandl <georg at python.org>,
|
||
Barry Warsaw <barry at python.org></dd>
|
||
<dt class="field-even">Status<span class="colon">:</span></dt>
|
||
<dd class="field-even"><abbr title="Inactive draft that may be taken up again at a later time">Deferred</abbr></dd>
|
||
<dt class="field-odd">Type<span class="colon">:</span></dt>
|
||
<dd class="field-odd"><abbr title="Normative PEP describing or proposing a change to a Python community process, workflow or governance">Process</abbr></dd>
|
||
<dt class="field-even">Created<span class="colon">:</span></dt>
|
||
<dd class="field-even">12-Jan-2012</dd>
|
||
<dt class="field-odd">Post-History<span class="colon">:</span></dt>
|
||
<dd class="field-odd">17-Jan-2012</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="#scope">Scope</a></li>
|
||
<li><a class="reference internal" href="#proposal">Proposal</a><ul>
|
||
<li><a class="reference internal" href="#periodicity">Periodicity</a></li>
|
||
<li><a class="reference internal" href="#pre-release-versions">Pre-release versions</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#effects">Effects</a><ul>
|
||
<li><a class="reference internal" href="#effect-on-development-cycle">Effect on development cycle</a></li>
|
||
<li><a class="reference internal" href="#effect-on-bugfix-cycle">Effect on bugfix cycle</a></li>
|
||
<li><a class="reference internal" href="#effect-on-workflow">Effect on workflow</a></li>
|
||
<li><a class="reference internal" href="#effect-on-the-community">Effect on the community</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#discussion">Discussion</a></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>Finding a release cycle for an open-source project is a delicate
|
||
exercise in managing mutually contradicting constraints: developer
|
||
manpower, availability of release management volunteers, ease of
|
||
maintenance for users and third-party packagers, quick availability of
|
||
new features (and behavioural changes), availability of bug fixes
|
||
without pulling in new features or behavioural changes.</p>
|
||
<p>The current release cycle errs on the conservative side. It is
|
||
adequate for people who value stability over reactivity. This PEP is
|
||
an attempt to keep the stability that has become a Python trademark,
|
||
while offering a more fluid release of features, by introducing the
|
||
notion of long-term support versions.</p>
|
||
</section>
|
||
<section id="scope">
|
||
<h2><a class="toc-backref" href="#scope" role="doc-backlink">Scope</a></h2>
|
||
<p>This PEP doesn’t try to change the maintenance period or release
|
||
scheme for the 2.7 branch. Only 3.x versions are considered.</p>
|
||
</section>
|
||
<section id="proposal">
|
||
<h2><a class="toc-backref" href="#proposal" role="doc-backlink">Proposal</a></h2>
|
||
<p>Under the proposed scheme, there would be two kinds of feature
|
||
versions (sometimes dubbed “minor versions”, for example 3.2 or 3.3):
|
||
normal feature versions and long-term support (LTS) versions.</p>
|
||
<p>Normal feature versions would get either zero or at most one bugfix
|
||
release; the latter only if needed to fix critical issues. Security
|
||
fix handling for these branches needs to be decided.</p>
|
||
<p>LTS versions would get regular bugfix releases until the next LTS
|
||
version is out. They then would go into security fixes mode, up to a
|
||
termination date at the release manager’s discretion.</p>
|
||
<section id="periodicity">
|
||
<h3><a class="toc-backref" href="#periodicity" role="doc-backlink">Periodicity</a></h3>
|
||
<p>A new feature version would be released every X months. We
|
||
tentatively propose X = 6 months.</p>
|
||
<p>LTS versions would be one out of N feature versions. We tentatively
|
||
propose N = 4.</p>
|
||
<p>With these figures, a new LTS version would be out every 24 months,
|
||
and remain supported until the next LTS version 24 months later. This
|
||
is mildly similar to today’s 18 months bugfix cycle for every feature
|
||
version.</p>
|
||
</section>
|
||
<section id="pre-release-versions">
|
||
<h3><a class="toc-backref" href="#pre-release-versions" role="doc-backlink">Pre-release versions</a></h3>
|
||
<p>More frequent feature releases imply a smaller number of disruptive
|
||
changes per release. Therefore, the number of pre-release builds
|
||
(alphas and betas) can be brought down considerably. Two alpha builds
|
||
and a single beta build would probably be enough in the regular case.
|
||
The number of release candidates depends, as usual, on the number of
|
||
last-minute fixes before final release.</p>
|
||
</section>
|
||
</section>
|
||
<section id="effects">
|
||
<h2><a class="toc-backref" href="#effects" role="doc-backlink">Effects</a></h2>
|
||
<section id="effect-on-development-cycle">
|
||
<h3><a class="toc-backref" href="#effect-on-development-cycle" role="doc-backlink">Effect on development cycle</a></h3>
|
||
<p>More feature releases might mean more stress on the development and
|
||
release management teams. This is quantitatively alleviated by the
|
||
smaller number of pre-release versions; and qualitatively by the
|
||
lesser amount of disruptive changes (meaning less potential for
|
||
breakage). The shorter feature freeze period (after the first beta
|
||
build until the final release) is easier to accept. The rush for
|
||
adding features just before feature freeze should also be much
|
||
smaller.</p>
|
||
</section>
|
||
<section id="effect-on-bugfix-cycle">
|
||
<h3><a class="toc-backref" href="#effect-on-bugfix-cycle" role="doc-backlink">Effect on bugfix cycle</a></h3>
|
||
<p>The effect on fixing bugs should be minimal with the proposed figures.
|
||
The same number of branches would be simultaneously open for bugfix
|
||
maintenance (two until 2.x is terminated, then one).</p>
|
||
</section>
|
||
<section id="effect-on-workflow">
|
||
<h3><a class="toc-backref" href="#effect-on-workflow" role="doc-backlink">Effect on workflow</a></h3>
|
||
<p>The workflow for new features would be the same: developers would only
|
||
commit them on the <code class="docutils literal notranslate"><span class="pre">default</span></code> branch.</p>
|
||
<p>The workflow for bug fixes would be slightly updated: developers would
|
||
commit bug fixes to the current LTS branch (for example <code class="docutils literal notranslate"><span class="pre">3.3</span></code>) and
|
||
then merge them into <code class="docutils literal notranslate"><span class="pre">default</span></code>.</p>
|
||
<p>If some critical fixes are needed to a non-LTS version, they can be
|
||
grafted from the current LTS branch to the non-LTS branch, just like
|
||
fixes are ported from 3.x to 2.7 today.</p>
|
||
</section>
|
||
<section id="effect-on-the-community">
|
||
<h3><a class="toc-backref" href="#effect-on-the-community" role="doc-backlink">Effect on the community</a></h3>
|
||
<p>People who value stability can just synchronize on the LTS releases
|
||
which, with the proposed figures, would give a similar support cycle
|
||
(both in duration and in stability).</p>
|
||
<p>People who value reactivity and access to new features (without taking
|
||
the risk to install alpha versions or Mercurial snapshots) would get
|
||
much more value from the new release cycle than currently.</p>
|
||
<p>People who want to contribute new features or improvements would be
|
||
more motivated to do so, knowing that their contributions will be more
|
||
quickly available to normal users. Also, a smaller feature freeze
|
||
period makes it less cumbersome to interact with contributors of
|
||
features.</p>
|
||
</section>
|
||
</section>
|
||
<section id="discussion">
|
||
<h2><a class="toc-backref" href="#discussion" role="doc-backlink">Discussion</a></h2>
|
||
<p>These are open issues that should be worked out during discussion:</p>
|
||
<ul class="simple">
|
||
<li>Decide on X (months between feature releases) and N (feature releases
|
||
per LTS release) as defined above.</li>
|
||
<li>For given values of X and N, is the no-bugfix-releases policy for
|
||
non-LTS versions feasible?</li>
|
||
<li>What is the policy for security fixes?</li>
|
||
<li>Restrict new syntax and similar changes (i.e. everything that was
|
||
prohibited by <a class="pep reference internal" href="../pep-3003/" title="PEP 3003 – Python Language Moratorium">PEP 3003</a>) to LTS versions?</li>
|
||
<li>What is the effect on packagers such as Linux distributions?</li>
|
||
<li>How will release version numbers or other identifying and marketing
|
||
material make it clear to users which versions are normal feature
|
||
releases and which are LTS releases? How do we manage user
|
||
expectations?</li>
|
||
<li>Does the faster release cycle mean we could some day reach 3.10 and
|
||
above? Some people expressed a tacit expectation that version numbers
|
||
always fit in one decimal digit.</li>
|
||
</ul>
|
||
<p>A community poll or survey to collect opinions from the greater Python
|
||
community would be valuable before making a final decision.</p>
|
||
</section>
|
||
<section id="copyright">
|
||
<h2><a class="toc-backref" href="#copyright" role="doc-backlink">Copyright</a></h2>
|
||
<p>This document has been placed in the public domain.</p>
|
||
</section>
|
||
</section>
|
||
<hr class="docutils" />
|
||
<p>Source: <a class="reference external" href="https://github.com/python/peps/blob/main/peps/pep-0407.rst">https://github.com/python/peps/blob/main/peps/pep-0407.rst</a></p>
|
||
<p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0407.rst">2023-09-09 17:39:29 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="#scope">Scope</a></li>
|
||
<li><a class="reference internal" href="#proposal">Proposal</a><ul>
|
||
<li><a class="reference internal" href="#periodicity">Periodicity</a></li>
|
||
<li><a class="reference internal" href="#pre-release-versions">Pre-release versions</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#effects">Effects</a><ul>
|
||
<li><a class="reference internal" href="#effect-on-development-cycle">Effect on development cycle</a></li>
|
||
<li><a class="reference internal" href="#effect-on-bugfix-cycle">Effect on bugfix cycle</a></li>
|
||
<li><a class="reference internal" href="#effect-on-workflow">Effect on workflow</a></li>
|
||
<li><a class="reference internal" href="#effect-on-the-community">Effect on the community</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#discussion">Discussion</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-0407.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> |