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:

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.

Other policies may depend on the release cadence

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.

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

Keep “4 betas over 4 months and a final month for the release candidate”

While this would make the release calendar a bit cleaner, it would make it very hard for external distributors like Fedora 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 as both are being developed which makes both projects better.

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.