python-peps/pep-0596.rst

PEP: 596
Title: Python 3.9 Release Schedule
Version: $Revision$
Last-Modified: $Date$
Author: Łukasz Langa <lukasz@python.org>
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: