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 602 – Annual Release Cycle for Python | peps.python.org</title> <link rel="shortcut icon" href="../_static/py.png"> <link rel="canonical" href="https://peps.python.org/pep-0602/"> <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 602 – Annual Release Cycle for Python | peps.python.org'> <meta property="og:description" content="This document describes a change in the release calendar for Python starting with Python 3.9. This change accelerates the release cadence such that feature versions are released predictably every twelve months, in October every year."> <meta property="og:type" content="website"> <meta property="og:url" content="https://peps.python.org/pep-0602/"> <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="This document describes a change in the release calendar for Python starting with Python 3.9. This change accelerates the release cadence such that feature versions are released predictably every twelve months, in October every year."> <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 602</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 602 – Annual Release Cycle for Python</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></dd> <dt class="field-even">PEP-Delegate<span class="colon">:</span></dt> <dd class="field-even">Brett Cannon <brett at python.org></dd> <dt class="field-odd">Discussions-To<span class="colon">:</span></dt> <dd class="field-odd"><a class="reference external" href="https://discuss.python.org/t/pep-602-annual-release-cycle-for-python/2296/">Discourse thread</a></dd> <dt class="field-even">Status<span class="colon">:</span></dt> <dd class="field-even"><abbr title="Currently valid informational guidance, or an in-use process">Active</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">04-Jun-2019</dd> <dt class="field-odd">Python-Version<span class="colon">:</span></dt> <dd class="field-odd">3.9</dd> <dt class="field-even">Post-History<span class="colon">:</span></dt> <dd class="field-even"><a class="reference external" href="https://discuss.python.org/t/27002" title="Discourse thread">09-Oct-2023</a></dd> <dt class="field-odd">Resolution<span class="colon">:</span></dt> <dd class="field-odd"><a class="reference external" href="https://mail.python.org/archives/list/python-dev@python.org/thread/KE7OS4PZASZMFTW2FP2MWZU5R4Q2QZKU/">Python-Dev thread</a></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="#implementation">Implementation</a><ul> <li><a class="reference internal" href="#seventeen-months-to-develop-a-feature-version">Seventeen months to develop a feature version</a></li> <li><a class="reference internal" href="#years-of-full-support-3-more-years-of-security-fixes">2 years of full support, 3 more years of security fixes</a></li> <li><a class="reference internal" href="#annual-release-cadence">Annual release cadence</a></li> </ul> </li> <li><a class="reference internal" href="#example">Example</a></li> <li><a class="reference internal" href="#dependent-policies">Dependent Policies</a><ul> <li><a class="reference internal" href="#deprecations">Deprecations</a></li> <li><a class="reference internal" href="#the-term-of-the-steering-council">The term of the Steering Council</a></li> <li><a class="reference internal" href="#the-term-of-the-release-manager">The term of the Release Manager</a></li> </ul> </li> <li><a class="reference internal" href="#rationale-and-goals">Rationale and Goals</a><ul> <li><a class="reference internal" href="#non-goals">Non-goals</a></li> <li><a class="reference internal" href="#non-risks">Non-risks</a></li> <li><a class="reference internal" href="#risks">Risks</a><ul> <li><a class="reference internal" href="#python-redistribution">Python redistribution</a></li> <li><a class="reference internal" href="#the-testing-matrix">The testing matrix</a></li> <li><a class="reference internal" href="#other-policies-may-depend-on-the-release-cadence">Other policies may depend on the release cadence</a></li> </ul> </li> <li><a class="reference internal" href="#rejected-ideas">Rejected Ideas</a><ul> <li><a class="reference internal" href="#keep-the-current-18-month-release-cadence">Keep the current 18 month release cadence</a></li> <li><a class="reference internal" href="#double-the-release-cadence-to-achieve-9-months-between-feature-versions">Double the release cadence to achieve 9 months between feature versions</a></li> <li><a class="reference internal" href="#keep-4-betas-over-4-months-and-a-final-month-for-the-release-candidate">Keep “4 betas over 4 months and a final month for the release candidate”</a></li> <li><a class="reference internal" href="#slow-down-releases-but-don-t-freeze-feature-development-with-beta-1">Slow down releases but don’t freeze feature development with Beta 1</a></li> <li><a class="reference internal" href="#long-term-support-releases">Long-Term Support Releases</a></li> </ul> </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>This document describes a change in the release calendar for Python starting with Python 3.9. This change accelerates the release cadence such that feature versions are released predictably every twelve months, in October every year.</p> </section> <section id="implementation"> <h2><a class="toc-backref" href="#implementation" role="doc-backlink">Implementation</a></h2> <section id="seventeen-months-to-develop-a-feature-version"> <h3><a class="toc-backref" href="#seventeen-months-to-develop-a-feature-version" role="doc-backlink">Seventeen months to develop a feature version</a></h3> <p>This PEP proposes that Python 3.X.0 will be developed for around 17 months:</p> <ul class="simple"> <li>The first <em>five months</em> overlap with Python 3.(X-1).0’s beta and release candidate stages and are thus unversioned.</li> <li>The next <em>seven months</em> are spent on versioned alpha releases where both new features are incrementally added and bug fixes are included.</li> <li>The following <em>three months</em> are spent on four versioned beta releases where <strong>no new features</strong> can be added but bug fixes are still included.</li> <li>The final <em>two months</em> are spent on two release candidates (or more, if necessary) and conclude with the release of the final release of Python 3.X.0.</li> </ul> </section> <section id="years-of-full-support-3-more-years-of-security-fixes"> <h3><a class="toc-backref" href="#years-of-full-support-3-more-years-of-security-fixes" role="doc-backlink">2 years of full support, 3 more years of security fixes</a></h3> <p>After the release of Python 3.X.0, the 3.X series is maintained for five years:</p> <ul class="simple"> <li>During the <em>first twenty four months</em> (2 years) it receives bugfix updates and full releases (sources and installers for Windows and macOS) are made approximately every other month.</li> <li>For the next <em>thirty six months</em> (3 years) it receives security updates and source-only releases are made on an as-needed basis (no fixed cadence).</li> <li>The final source-only release is made <em>five years</em> after 3.X.0.</li> </ul> <p>Note: 2 years of full support start with <a class="pep reference internal" href="../pep-0719/" title="PEP 719 – Python 3.13 Release Schedule">Python 3.13</a>. Python versions 3.9 - 3.12 operate on a calendar with 1½ year of full support, followed by 3½ more years of security fixes.</p> </section> <section id="annual-release-cadence"> <h3><a class="toc-backref" href="#annual-release-cadence" role="doc-backlink">Annual release cadence</a></h3> <p>Feature development of Python 3.(X+1).0 starts as soon as Python 3.X.0 Beta 1 is released. This creates a twelve-month delta between Python feature versions.</p> </section> </section> <section id="example"> <h2><a class="toc-backref" href="#example" role="doc-backlink">Example</a></h2> <ul class="simple"> <li>3.9 development begins: Tuesday, 2019-06-04</li> <li>3.9.0 alpha 1: Monday, 2019-10-14</li> <li>3.9.0 alpha 2: Monday, 2019-11-18</li> <li>3.9.0 alpha 3: Monday, 2019-12-16</li> <li>3.9.0 alpha 4: Monday, 2020-01-13</li> <li>3.9.0 alpha 5: Monday, 2020-02-17</li> <li>3.9.0 alpha 6: Monday, 2020-03-16</li> <li>3.9.0 alpha 7: Monday, 2020-04-13</li> <li>3.9.0 beta 1: Monday, 2020-05-18 (No new features beyond this point.)</li> <li>3.9.0 beta 2: Monday, 2020-06-08</li> <li>3.9.0 beta 3: Monday, 2020-06-29</li> <li>3.9.0 beta 4: Monday, 2020-07-20</li> <li>3.9.0 candidate 1: Monday, 2020-08-10</li> <li>3.9.0 candidate 2: Monday, 2020-09-14</li> <li>3.9.0 final: Monday, 2020-10-05</li> </ul> <figure class="align-center" id="id1"> <a class="reference internal image-reference" href="../_images/pep-0602-example-release-calendar.png"><img alt="../_images/pep-0602-example-release-calendar.png" src="../_images/pep-0602-example-release-calendar.png" style="width: 100%;" /> </a> <figcaption> <p><span class="caption-text">Figure 1. Consequences of the annual release cycle on the calendar.</span></p> </figcaption> </figure> <p>In comparison, if this PEP is rejected and Python keeps the current release schedule:</p> <ul class="simple"> <li>3.9 development begins: Tuesday, 2019-06-04</li> <li>3.9.0 alpha 1: Monday, 2020-08-03 (10 months later)</li> <li>3.9.0 alpha 2: Monday, 2020-09-07</li> <li>3.9.0 alpha 3: Monday, 2020-10-05</li> <li>3.9.0 alpha 4: Monday, 2020-11-02</li> <li>3.9.0 beta 1: Monday, 2020-11-30 (6 months later)</li> <li>3.9.0 beta 2: Monday, 2021-01-04</li> <li>3.9.0 beta 3: Monday, 2021-02-01</li> <li>3.9.0 beta 4: Monday, 2021-03-01</li> <li>3.9.0 candidate 1: Monday, 2021-03-29</li> <li>3.9.0 candidate 2: Monday, 2021-04-05 (if necessary)</li> <li>3.9.0 final: Monday, 2021-04-19 (6 months later)</li> </ul> </section> <section id="dependent-policies"> <h2><a class="toc-backref" href="#dependent-policies" role="doc-backlink">Dependent Policies</a></h2> <section id="deprecations"> <h3><a class="toc-backref" href="#deprecations" role="doc-backlink">Deprecations</a></h3> <p>The current policy around breaking changes assumes at least two releases before a deprecated feature is removed from Python or a <code class="docutils literal notranslate"><span class="pre">__future__</span></code> behavior is enabled by default. This is documented in <a class="pep reference internal" href="../pep-0387/" title="PEP 387 – Backwards Compatibility Policy">PEP 387</a>.</p> <p>This PEP proposes to keep this policy of <strong>at least</strong> two releases before making a breaking change.</p> </section> <section id="the-term-of-the-steering-council"> <h3><a class="toc-backref" href="#the-term-of-the-steering-council" role="doc-backlink">The term of the Steering Council</a></h3> <p>The current wording of <a class="pep reference internal" href="../pep-0013/" title="PEP 13 – Python Language Governance">PEP 13</a> states that “a new council is elected after each feature release”. This PEP proposes to keep this policy as it will lead to a consistent election schedule.</p> </section> <section id="the-term-of-the-release-manager"> <h3><a class="toc-backref" href="#the-term-of-the-release-manager" role="doc-backlink">The term of the Release Manager</a></h3> <p>The current undocumented convention is for a single Release Manager to handle two feature releases of Python. This PEP proposes to keep this policy, allowing for the term to be extended to more releases with approval from the Steering Council and the Cabal of Release Managers.</p> <p>In particular, since this PEP is authored by the active Release Manager and its effect would shorten the term of the Release Manager, the author is open to managing the release of a third feature release to compensate for the disruption.</p> </section> </section> <section id="rationale-and-goals"> <h2><a class="toc-backref" href="#rationale-and-goals" role="doc-backlink">Rationale and Goals</a></h2> <p>This change provides the following advantages:</p> <ul class="simple"> <li>makes releases smaller: since doubling the cadence doesn’t double our available development resources, consecutive releases are going to be smaller in terms of features;</li> <li>puts features and bug fixes in hands of users sooner;</li> <li>creates a more gradual upgrade path for users, by decreasing the surface of change in any single release;</li> <li>creates a predictable calendar for releases where the final release is always in October (so after the annual core sprint), and the beta phase starts in late May (so after PyCon US sprints), which is especially important for core developers who need to plan to include Python involvement in their calendar;</li> <li>decreases the urge to rush features shortly before “Beta 1” due to the risk of them “slipping for 18 months”;</li> <li>allows for synchronizing the schedule of Python release management with external distributors like Fedora who’ve been historically very helpful in finding regressions early not only in core Python but also in third-party libraries, helping moving the community forward to support the latest version of Python from Day 1;</li> <li>increases the explicit alpha release phase, which provides meaningful snapshots of progress on new features;</li> <li>significantly cuts the implicit “alpha 0” release phase which provides limited use for new development anyway (it overlaps with the beta of the <em>currently developed</em>, still unreleased, version).</li> </ul> <section id="non-goals"> <h3><a class="toc-backref" href="#non-goals" role="doc-backlink">Non-goals</a></h3> <p>Adopting an annual release calendar allows for natural switching to calendar versioning, for example by calling Python 3.9 “Python 3.20” since it’s released in October ‘20 and so on (“Python 3.23” would be the one released in October ‘23).</p> <p>While the ease of switching to calendar versioning can be treated as an advantage of an annual release cycle, this PEP does not advocate for or against a change in how Python is versioned. Should the annual release cycle be adopted, the versioning question will be dealt with in a separate PEP.</p> </section> <section id="non-risks"> <h3><a class="toc-backref" href="#non-risks" role="doc-backlink">Non-risks</a></h3> <p>This change does not shorten the currently documented support calendar for a Python release, both in terms of bugfix releases and security fixes.</p> <p>This change does not accelerate the velocity of development. Python is not going to become incompatible faster or accrue new features faster. It’s just that features are going to be released more gradually as they are developed.</p> <p>Consequently, while this change introduces the ability for users to upgrade much faster, it does not require them to do so. Say, if they upgrade every second release, their experience with Python is going to be similar to the current situation.</p> </section> <section id="risks"> <h3><a class="toc-backref" href="#risks" role="doc-backlink">Risks</a></h3> <section id="python-redistribution"> <h4><a class="toc-backref" href="#python-redistribution" role="doc-backlink">Python redistribution</a></h4> <p>This requires changes to how integrators, like Linux distributions, release Python within their systems.</p> </section> <section id="the-testing-matrix"> <h4><a class="toc-backref" href="#the-testing-matrix" role="doc-backlink">The testing matrix</a></h4> <p>This eventually increases the testing matrix for library and application maintainers that want to support all actively supported Python versions by one or two:</p> <figure class="align-center" id="id2"> <a class="reference internal image-reference" href="../_images/pep-0602-overlapping-support-matrix.png"><img alt="../_images/pep-0602-overlapping-support-matrix.png" src="../_images/pep-0602-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 12-month</span></p> </figcaption> </figure> <p>The “extended bugfix support at the discretion of the Release Manager” stage of the current release cycle is not codified. If fact, <a class="pep reference internal" href="../pep-0101/" title="PEP 101 – Doing Python Releases 101">PEP 101</a> currently states that after the release of Python 3.(X+1).0 only one last bugfix release is made for Python 3.X.0. However, in practice at least the last four versions of Python 3 overlapped with stable releases of the next version for around six months. Figure 2 is including this information to demonstrate that overlap between stable version releases with the 12-month release cadence will be nothing new.</p> </section> <section id="other-policies-may-depend-on-the-release-cadence"> <h4><a class="toc-backref" href="#other-policies-may-depend-on-the-release-cadence" role="doc-backlink">Other policies may depend on the release cadence</a></h4> <p>Although identified dependent policies were addressed in a previous section, it is entirely possible there are some other areas which implicitly rely on the timing of Python releases.</p> </section> </section> <section id="rejected-ideas"> <h3><a class="toc-backref" href="#rejected-ideas" role="doc-backlink">Rejected Ideas</a></h3> <section id="keep-the-current-18-month-release-cadence"> <h4><a class="toc-backref" href="#keep-the-current-18-month-release-cadence" role="doc-backlink">Keep the current 18 month release cadence</a></h4> <p>This is undesirable both for core developers and end users. From the perspective of the core developer:</p> <ul class="simple"> <li>it makes contribution scheduling harder due to irregular release dates every year;</li> <li>it creates a surge of rushed commits before (and even after!) Beta 1 due to the stress involved with “missing a release”;</li> <li>ironically, after Beta 1 it creates a false sense of having “plenty of time” before the next release, time that passes quickly regardless;</li> <li>it causes certain elements of the workflow to be executed so rarely that they are not explicitly documented, let alone automated.</li> </ul> <p>More importantly, from the perspective of the user:</p> <ul class="simple"> <li>it creates releases with many new features, some being explicitly incompatible and some being accidentally incompatible, which makes the upgrade cost relatively high every time;</li> <li>it sits on features and incompatible bug fixes for over a year before becoming available to the user; and more specifically</li> <li>it causes every “point zero” release to be extra risky for users. While we provide and recommend testing with alphas and betas, “point zero” is the first release of a given Python version for many users. The bigger a release is feature-wise, the more potential problems are hiding in “point zero releases”.</li> </ul> </section> <section id="double-the-release-cadence-to-achieve-9-months-between-feature-versions"> <h4><a class="toc-backref" href="#double-the-release-cadence-to-achieve-9-months-between-feature-versions" role="doc-backlink">Double the release cadence to achieve 9 months between feature versions</a></h4> <p>This was originally proposed in <a class="pep reference internal" href="../pep-0596/" title="PEP 596 – Python 3.9 Release Schedule">PEP 596</a> and rejected as both too irregular and too short. This would not give any of the benefits of a regular release calendar but it would shorten all development phases, especially the beta + RC phases. This was considered dangerous.</p> </section> <section id="keep-4-betas-over-4-months-and-a-final-month-for-the-release-candidate"> <h4><a class="toc-backref" href="#keep-4-betas-over-4-months-and-a-final-month-for-the-release-candidate" role="doc-backlink">Keep “4 betas over 4 months and a final month for the release candidate”</a></h4> <p>While this would make the release calendar a bit cleaner, <a class="reference external" href="https://discuss.python.org/t/pep-602-annual-release-cycle-for-python/2296/79?u=ambv">it would make it very hard for external distributors like Fedora</a> to release the newest version of Python as soon as possible. We are adjusting Python’s calendar here in the hope that this will enable Fedora to integrate the newest version of Python with the newest version of Fedora <em>as both are being developed</em> which makes both projects better.</p> </section> <section id="slow-down-releases-but-don-t-freeze-feature-development-with-beta-1"> <h4><a class="toc-backref" href="#slow-down-releases-but-don-t-freeze-feature-development-with-beta-1" role="doc-backlink">Slow down releases but don’t freeze feature development with Beta 1</a></h4> <p>This is described in <a class="pep reference internal" href="../pep-0598/" title="PEP 598 – Introducing incremental feature releases">PEP 598</a>. This proposal includes non-standard concepts like the “incremental feature release” which makes it hard to understand. The presented advantages are unclear while the unfamiliarity of the scheme poses a real risk of user and integrator confusion.</p> </section> <section id="long-term-support-releases"> <h4><a class="toc-backref" href="#long-term-support-releases" role="doc-backlink">Long-Term Support Releases</a></h4> <p>Each version of Python is effectively long-term support: it’s supported for five years, with the first eighteen months allowing regular bug fixes and security updates. For the remaining time security updates are accepted and promptly released.</p> <p>No extended support in the vein of Python 2.7 is planned going forward.</p> </section> </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-0602.rst">https://github.com/python/peps/blob/main/peps/pep-0602.rst</a></p> <p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0602.rst">2024-05-28 05:47:01 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="#implementation">Implementation</a><ul> <li><a class="reference internal" href="#seventeen-months-to-develop-a-feature-version">Seventeen months to develop a feature version</a></li> <li><a class="reference internal" href="#years-of-full-support-3-more-years-of-security-fixes">2 years of full support, 3 more years of security fixes</a></li> <li><a class="reference internal" href="#annual-release-cadence">Annual release cadence</a></li> </ul> </li> <li><a class="reference internal" href="#example">Example</a></li> <li><a class="reference internal" href="#dependent-policies">Dependent Policies</a><ul> <li><a class="reference internal" href="#deprecations">Deprecations</a></li> <li><a class="reference internal" href="#the-term-of-the-steering-council">The term of the Steering Council</a></li> <li><a class="reference internal" href="#the-term-of-the-release-manager">The term of the Release Manager</a></li> </ul> </li> <li><a class="reference internal" href="#rationale-and-goals">Rationale and Goals</a><ul> <li><a class="reference internal" href="#non-goals">Non-goals</a></li> <li><a class="reference internal" href="#non-risks">Non-risks</a></li> <li><a class="reference internal" href="#risks">Risks</a><ul> <li><a class="reference internal" href="#python-redistribution">Python redistribution</a></li> <li><a class="reference internal" href="#the-testing-matrix">The testing matrix</a></li> <li><a class="reference internal" href="#other-policies-may-depend-on-the-release-cadence">Other policies may depend on the release cadence</a></li> </ul> </li> <li><a class="reference internal" href="#rejected-ideas">Rejected Ideas</a><ul> <li><a class="reference internal" href="#keep-the-current-18-month-release-cadence">Keep the current 18 month release cadence</a></li> <li><a class="reference internal" href="#double-the-release-cadence-to-achieve-9-months-between-feature-versions">Double the release cadence to achieve 9 months between feature versions</a></li> <li><a class="reference internal" href="#keep-4-betas-over-4-months-and-a-final-month-for-the-release-candidate">Keep “4 betas over 4 months and a final month for the release candidate”</a></li> <li><a class="reference internal" href="#slow-down-releases-but-don-t-freeze-feature-development-with-beta-1">Slow down releases but don’t freeze feature development with Beta 1</a></li> <li><a class="reference internal" href="#long-term-support-releases">Long-Term Support Releases</a></li> </ul> </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-0602.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>