295 lines
9.9 KiB
ReStructuredText
295 lines
9.9 KiB
ReStructuredText
PEP: 602
|
||
Title: Annual Release Cycle for Python
|
||
Version: $Revision$
|
||
Last-Modified: $Date$
|
||
Author: Łukasz Langa <lukasz@python.org>
|
||
Discussions-To: https://discuss.python.org/t/pep-602-annual-release-cycle-for-python/2296/
|
||
Status: Draft
|
||
Type: Informational
|
||
Content-Type: text/x-rst
|
||
Created: 04-Jun-2019
|
||
Python-Version: 3.9
|
||
|
||
|
||
Abstract
|
||
========
|
||
|
||
This document describes a change in the release calendar for Python
|
||
starting with Python 3.9. This change accelerates the release cadence
|
||
such that major versions are released predictably every twelve months,
|
||
in October every year.
|
||
|
||
|
||
Implementation
|
||
==============
|
||
|
||
Seventeen months to develop a major version
|
||
-------------------------------------------
|
||
|
||
This PEP proposes that Python 3.X.0 will be developed for around
|
||
17 months:
|
||
|
||
- The first *five months* overlap with Python 3.(X-1).0's beta
|
||
and release candidate stages and are thus unversioned.
|
||
|
||
- The next *seven months* are spent on versioned alpha releases where
|
||
both new features are incrementally added and bug fixes are included.
|
||
|
||
- The following *four months* are spent on versioned beta releases where
|
||
**no new features** can be added but bug fixes are still included.
|
||
|
||
- The *final month* is spent on a release candidate (or more, if
|
||
necessary) and concludes with the release of the final release of
|
||
Python 3.X.0.
|
||
|
||
One year of full support, four more years of security fixes
|
||
-----------------------------------------------------------
|
||
|
||
After the release of Python 3.X.0, the 3.X series is maintained for
|
||
five years:
|
||
|
||
- During the *first eighteen months* (1½ year) it receives bugfix
|
||
updates and full releases (sources and installers for Windows and
|
||
macOS) are made approximately every other month.
|
||
|
||
- For the next *forty two months* (3½ years) it receives security
|
||
updates and source-only releases are made on an as-needed basis
|
||
(no fixed cadence).
|
||
|
||
- The final source-only release is made *five years* after 3.X.0.
|
||
|
||
Annual release cadence
|
||
----------------------
|
||
|
||
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 major Python versions.
|
||
|
||
|
||
Example
|
||
=======
|
||
|
||
- 3.9 development begins: Tuesday, 2019-06-04
|
||
- 3.9.0 alpha 1: Monday, 2019-10-14
|
||
- 3.9.0 alpha 2: Monday, 2019-11-18
|
||
- 3.9.0 alpha 3: Monday, 2019-12-16
|
||
- 3.9.0 alpha 4: Monday, 2020-01-13
|
||
- 3.9.0 alpha 5: Monday, 2020-02-17
|
||
- 3.9.0 alpha 6: Monday, 2020-03-16
|
||
- 3.9.0 alpha 7: Monday, 2020-04-13
|
||
- 3.9.0 beta 1: Monday, 2020-05-18
|
||
(No new features beyond this point.)
|
||
|
||
- 3.9.0 beta 2: Monday, 2020-06-15
|
||
- 3.9.0 beta 3: Monday, 2020-07-13
|
||
- 3.9.0 beta 4: Monday, 2020-08-17
|
||
- 3.9.0 candidate 1: Monday, 2020-09-14
|
||
- 3.9.0 candidate 2: Monday, 2020-09-21 (if necessary)
|
||
- 3.9.0 final: Monday, 2020-10-05
|
||
|
||
.. figure:: pep-0602-example-release-calendar.png
|
||
:align: center
|
||
:width: 100%
|
||
|
||
Figure 1. Consequences of the annual release cycle on the calendar.
|
||
|
||
In comparison, if this PEP is rejected and Python keeps the current
|
||
release schedule:
|
||
|
||
- 3.9 development begins: Tuesday, 2019-06-04
|
||
- 3.9.0 alpha 1: Monday, 2020-08-03 (10 months later)
|
||
- 3.9.0 alpha 2: Monday, 2020-09-07
|
||
- 3.9.0 alpha 3: Monday, 2020-10-05
|
||
- 3.9.0 alpha 4: Monday, 2020-11-02
|
||
- 3.9.0 beta 1: Monday, 2020-11-30 (6 months later)
|
||
- 3.9.0 beta 2: Monday, 2021-01-04
|
||
- 3.9.0 beta 3: Monday, 2021-02-01
|
||
- 3.9.0 beta 4: Monday, 2021-03-01
|
||
- 3.9.0 candidate 1: Monday, 2021-03-29
|
||
- 3.9.0 candidate 2: Monday, 2021-04-05 (if necessary)
|
||
- 3.9.0 final: Monday, 2021-04-19 (6 months later)
|
||
|
||
|
||
|
||
Rationale and Goals
|
||
===================
|
||
|
||
This change provides the following advantages:
|
||
|
||
- 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;
|
||
|
||
- puts features and bug fixes in hands of users sooner;
|
||
|
||
- creates a more gradual upgrade path for users, by decreasing the
|
||
surface of change in any single release;
|
||
|
||
- 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;
|
||
|
||
- decreases the urge to rush features shortly before "Beta 1" due to
|
||
the risk of them "slipping for 18 months";
|
||
|
||
- increases the explicit alpha release phase, which provides meaningful
|
||
snapshots of progress on new features;
|
||
|
||
- significantly cuts the implicit "alpha 0" release phase which provides
|
||
limited use for new development anyway (it overlaps with the beta of
|
||
the *currently developed*, still unreleased, version);
|
||
|
||
Non-goals
|
||
---------
|
||
|
||
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).
|
||
|
||
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.
|
||
|
||
Non-risks
|
||
---------
|
||
|
||
This change does not shorten the currently documented support calendar
|
||
for a Python release, both in terms of bugfix releases and security
|
||
fixes.
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
Risks
|
||
-----
|
||
|
||
Python redistribution
|
||
~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
This requires changes to how integrators, like Linux distributions,
|
||
release Python within their systems.
|
||
|
||
The testing matrix
|
||
~~~~~~~~~~~~~~~~~~
|
||
|
||
This eventually increases the testing matrix for library and application
|
||
maintainers that want to support all actively supported Python versions
|
||
by one or two:
|
||
|
||
.. figure:: pep-0602-overlapping-support-matrix.png
|
||
:align: center
|
||
:width: 50%
|
||
|
||
Figure 2. Testing matrix in the 18-month cadence vs. the 12-month
|
||
|
||
The "extended bugfix support at the discretion of the Release Manager"
|
||
stage of the current release cycle is not codified. If fact, PEP 101
|
||
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.
|
||
|
||
Some policies depend on the release cadence
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
The following policies depend on the release cadence and will have to
|
||
be updated:
|
||
|
||
- the deprecation policy
|
||
- the``__future__`` import becoming the default
|
||
- the term of the Steering Council
|
||
- the term of the Release Manager
|
||
|
||
Rejected Ideas
|
||
--------------
|
||
|
||
Keep the current 18 month release cadence
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
This is undesirable both for core developers and end users. From the
|
||
perspective of the core developer:
|
||
|
||
- it makes contribution scheduling harder due to irregular release
|
||
dates every year;
|
||
|
||
- it creates a surge of rushed commits before (and even after!) Beta 1
|
||
due to the stress involved with "missing a release";
|
||
|
||
- ironically, after Beta 1 it creates a false sense of having "plenty of
|
||
time" before the next release, time that passes quickly regardless;
|
||
|
||
- it causes certain elements of the workflow to be executed so rarely
|
||
that they are not explicitly documented, let alone automated.
|
||
|
||
More importantly, from the perspective of the user:
|
||
|
||
- 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;
|
||
|
||
- it sits on features and incompatible bug fixes for over a year before
|
||
becoming available to the user; and more specifically
|
||
|
||
- 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".
|
||
|
||
Double the release cadence to achieve 9 months between major versions
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
This was originally proposed in PEP 596 and rejected as both too
|
||
irregular and too short. One consequence of a 9 month release cadence
|
||
was shortening of the beta phase and this was considered dangerous.
|
||
|
||
Slow down releases but don't freeze feature development with Beta 1
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
This is described in PEP 598. 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.
|
||
|
||
Long-Term Support Releases
|
||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||
|
||
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.
|
||
|
||
No extended support in the vein of Python 2.7 is planned going forward.
|
||
|
||
|
||
Copyright
|
||
=========
|
||
|
||
This document is placed in the public domain or under the
|
||
CC0-1.0-Universal license, whichever is more permissive.
|
||
|
||
|
||
..
|
||
Local Variables:
|
||
mode: indented-text
|
||
indent-tabs-mode: nil
|
||
sentence-end-double-space: t
|
||
fill-column: 72
|
||
coding: utf-8
|
||
End:
|