CINXE.COM

<!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>