Seventeen months to develop a feature version

This PEP proposes that Python 3.X.0 will be developed for around17 months:

• The firstfive months overlap with Python 3.(X-1).0’s betaand release candidate stages and are thus unversioned.
• The nextseven months are spent on versioned alpha releases whereboth new features are incrementally added and bug fixes are included.
• The followingthree months are spent on four versioned beta releaseswhereno new features can be added but bug fixes are stillincluded.
• The finaltwo months are spent on two release candidates (or more,if necessary) and conclude with the release of the final release ofPython 3.X.0.

2 years of full support, 3 more years of security fixes

After the release of Python 3.X.0, the 3.X series is maintained forfive years:

• During thefirst twenty four months (2 years) it receives bugfixupdates and full releases (sources and installers for Windows andmacOS) are made approximately every other month.
• For the nextthirty six months (3 years) it receives securityupdates and source-only releases are made on an as-needed basis(no fixed cadence).
• The final source-only release is madefive years after 3.X.0.

Note: 2 years of full support start withPython 3.13. Python versions3.9 - 3.12 operate on a calendar with 1½ year of full support, followedby 3½ more years of security fixes.

Annual release cadence

Feature development of Python 3.(X+1).0 starts as soon asPython 3.X.0 Beta 1 is released. This creates a twelve-month deltabetween Python feature versions.

Deprecations

The current policy around breaking changes assumes at least two releasesbefore a deprecated feature is removed from Python or a__future__behavior is enabled by default. This is documented inPEP 387.

This PEP proposes to keep this policy ofat least two releasesbefore making a breaking change.

The term of the Steering Council

The current wording ofPEP 13 states that “a new council is electedafter each feature release”. This PEP proposes to keep this policyas it will lead to a consistent election schedule.

The term of the Release Manager

The current undocumented convention is for a single Release Manager tohandle two feature releases of Python. This PEP proposes to keep thispolicy, allowing for the term to be extended to more releases withapproval from the Steering Council and the Cabal of Release Managers.

In particular, since this PEP is authored by the active Release Managerand its effect would shorten the term of the Release Manager, the authoris open to managing the release of a third feature release to compensatefor the disruption.

Non-goals

Adopting an annual release calendar allows for natural switching tocalendar 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 theone released in October ‘23).

While the ease of switching to calendar versioning can be treated asan advantage of an annual release cycle, this PEP does not advocate foror against a change in how Python is versioned. Should the annualrelease cycle be adopted, the versioning question will be dealt with ina separate PEP.

Non-risks

This change does not shorten the currently documented support calendarfor a Python release, both in terms of bugfix releases and securityfixes.

This change does not accelerate the velocity of development. Python isnot going to become incompatible faster or accrue new features faster.It’s just that features are going to be released more gradually as theyare developed.

Consequently, while this change introduces the ability for users toupgrade much faster, it does not require them to do so. Say, if theyupgrade every second release, their experience with Python is going tobe similar to the current situation.

Risks

The testing matrix

This eventually increases the testing matrix for library and applicationmaintainers that want to support all actively supported Python versionsby 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 101currently states that after the release of Python 3.(X+1).0 only onelast bugfix release is made for Python 3.X.0. However, in practice atleast the last four versions of Python 3 overlapped with stable releasesof the next version for around six months. Figure 2 is includingthis information to demonstrate that overlap between stable versionreleases with the 12-month release cadence will be nothing new.

Rejected Ideas