203 lines
6.3 KiB
ReStructuredText
203 lines
6.3 KiB
ReStructuredText
PEP: 596
|
||
Title: Python 3.9 Release Schedule
|
||
Version: $Revision$
|
||
Last-Modified: $Date$
|
||
Author: Łukasz Langa <lukasz@python.org>
|
||
Discussions-To: https://discuss.python.org/t/pep-596-python-3-9-release-schedule-doubling-the-release-cadence/1828
|
||
Status: Draft
|
||
Type: Informational
|
||
Content-Type: text/x-rst
|
||
Created: 04-Jun-2019
|
||
Python-Version: 3.9
|
||
|
||
|
||
Abstract
|
||
========
|
||
|
||
This document describes the development and release schedule for
|
||
Python 3.9. The schedule primarily concerns itself with PEP-sized
|
||
items.
|
||
|
||
.. Small features may be added up to the first beta
|
||
release. Bugs may be fixed until the final release,
|
||
which is planned for end of October 2019.
|
||
|
||
|
||
Release Manager and Crew
|
||
========================
|
||
|
||
- 3.9 Release Manager: Łukasz Langa
|
||
- Windows installers: Steve Dower
|
||
- Mac installers: Ned Deily
|
||
- Documentation: Julien Palard
|
||
|
||
|
||
3.9 Lifespan
|
||
============
|
||
|
||
3.9 will receive bugfix updates approximately every month for
|
||
approximately 12 months. After the release of 3.10.0 final, a final
|
||
3.9 bugfix update will be released. After that, it is expected that
|
||
security updates (source only) will be released until 5 years after
|
||
the release of 3.9 final, so until approximately June 2025.
|
||
|
||
|
||
Release Schedule
|
||
================
|
||
|
||
3.9.0 schedule
|
||
--------------
|
||
|
||
Note: the dates below are proposing a 9-month release cadence.
|
||
Rationale is described in sections below. This is not set in stone yet.
|
||
The PEP is in draft status. Suggestions and comments welcome.
|
||
|
||
Expected:
|
||
|
||
- 3.9 development begins: Tuesday, 2019-06-04
|
||
- 3.9.0 alpha 1: Friday, 2019-09-13
|
||
- 3.9.0 alpha 2: Monday, 2019-10-14
|
||
- 3.9.0 alpha 3: Monday, 2019-11-18
|
||
- 3.9.0 alpha 4: Monday, 2019-12-16
|
||
- 3.9.0 alpha 5: Tuesday, 2020-01-20
|
||
- 3.9.0 beta 1: Monday, 2020-02-17
|
||
(No new features beyond this point.)
|
||
|
||
- 3.9.0 beta 2: Monday, 2020-03-23
|
||
- 3.9.0 beta 3: Monday, 2020-04-20
|
||
- 3.9.0 candidate 1: Monday, 2020-05-18
|
||
- 3.9.0 candidate 2: Monday, 2020-05-25 (if necessary)
|
||
- 3.9.0 final: Monday, 2020-06-08
|
||
|
||
Subsequent bugfix releases at a monthly cadence.
|
||
|
||
|
||
Features for 3.9
|
||
================
|
||
|
||
Nothing yet, go write a PEP!
|
||
|
||
|
||
Moving to a nine month release calendar
|
||
=======================================
|
||
|
||
Rationale and Goals
|
||
-------------------
|
||
|
||
This PEP is proposing a release calendar that doubles the release
|
||
cadence. Python 3.9 will be developed for 12 months, 7 of which are
|
||
spent on feature development (pre-beta), while the remaining 5 are
|
||
spent on hardening the release (beta and RC). Due to feature development
|
||
starting as soon as Python 3.8 Beta 1 was released, this creates
|
||
a nine month delta between major Python releases.
|
||
|
||
This change provides the following advantages:
|
||
|
||
- makes releases smaller: doubling the cadence doesn't double our
|
||
available development resources, meaning that 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
|
||
|
||
- decreases the urge to rush features shortly before "Beta 1" due to
|
||
the risk of them "slipping for 18 months"
|
||
|
||
- shortens the beta phase, which also shortens the calendar overlap of
|
||
"hardening" the *currently developed* (still unreleased) release vs.
|
||
"feature development" on the *next* release
|
||
|
||
- 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 mostly overlaps with
|
||
the beta of the *currently developed*, still unreleased, version)
|
||
|
||
Non-risks
|
||
---------
|
||
|
||
This change does not shorten the security updates calendar for a Python
|
||
release.
|
||
|
||
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 twice as fast, it does not require them to do so. Say, if they
|
||
upgrade every second release, their experience with Python is going to
|
||
be very similar to the current situation.
|
||
|
||
Risks
|
||
-----
|
||
|
||
This requires changes to how integrators, like Linux distributions,
|
||
release Python within their systems.
|
||
|
||
This eventually doubles the testing matrix for library and application
|
||
maintainers that want to support all actively supported Python versions.
|
||
|
||
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
|
||
|
||
Finally, this shortens the bugfix period to twelve months. This allows
|
||
core developers to increase the cadence without increasing the biggest
|
||
maintenance cost, however provides an inconvenience to the user. This
|
||
particular risk might be solved by making every n-th release a LTS, in
|
||
the vein of Python 2.7. This is open for debate.
|
||
|
||
Rejected Ideas
|
||
--------------
|
||
|
||
Keep the current 18 month release cadence. From the perspective of the
|
||
core developer:
|
||
|
||
- 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".
|
||
|
||
|
||
Copyright
|
||
=========
|
||
|
||
This document has been placed in the public domain.
|
||
|
||
|
||
..
|
||
Local Variables:
|
||
mode: indented-text
|
||
indent-tabs-mode: nil
|
||
sentence-end-double-space: t
|
||
fill-column: 72
|
||
coding: utf-8
|
||
End:
|