This document describes the development and release schedule for Python 3.9. The schedule primarily concerns itself with PEP-sized items.
Release Manager and Crew
- 3.9 Release Manager: Łukasz Langa
- Windows installers: Steve Dower
- Mac installers: Ned Deily
- Documentation: Julien Palard
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.
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.
- 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)
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.
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
__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.
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”.