Development cycle¶

In-development (main) branch¶

The main branch is the branch for the next feature release; it is under active development for all kinds of changes: new features, semantic changes, performance improvements, bug fixes.

At some point during the life-cycle of a release, a new maintenance branch is created to host all bug fixing activity for further micro versions in a feature version (3.12.1, 3.12.2, and so on).

We create the release maintenance branch (3.14) at the time we enter beta (3.14.0 beta 1). This allows feature development for the release 3.n+1 to occur within the main branch alongside the beta and release candidate stabilization periods for release 3.n.

Maintenance branches¶

A branch for a previous feature release, currently being maintained for bug fixes, or for the next feature release in its beta or release candidate stages. There are usually either one or two maintenance branches at any given time. After the final release of a new minor version (3.x.0), releases produced from a maintenance branch are called bugfix or maintenance releases; the terms are used interchangeably. These releases have a micro version number greater than zero.

Changes backported to a maintenance branch fall into two groups. Low-risk changes (bug fixes, test improvements, and documentation edits) may be backported without debate. Higher-risk changes (new features, semantic changes, and performance improvements) can introduce regressions, so they are not backported as a matter of course. Also, a general rule for maintenance branches is that compatibility must not be broken at any point between sibling micro releases (3.12.1, 3.12.2, etc.). For both rules, only rare exceptions are accepted, and each requires a strong case agreed upon in discussion beforehand.

Backporting changes reduces the risk of future conflicts. For documentation, it increases the visibility of improvements, since most readers access the stable documentation rather than the development documentation.

A new maintenance branch is normally created when the next feature release cycle reaches feature freeze, that is, at its first beta pre-release. From that point on, changes intended for remaining pre-releases, the final release (3.x.0), and subsequent bugfix releases are merged to that maintenance branch.

Sometime following the final release (3.x.0), the maintenance branch for the previous minor version will go into security mode, usually after at least one more bugfix release at the discretion of the release manager. For example, the 3.11 maintenance branch was put into security mode after the 3.11.9 bugfix release which followed the release of 3.12.2.

Security branches¶

A branch less than 5 years old but no longer in bugfix mode is a security branch.

The only changes made to a security branch are those fixing issues exploitable by attackers such as crashes, privilege escalation and, optionally, other issues such as denial of service attacks. Any other changes are not considered a security risk and thus not backported to a security branch. You should also consider fixing hard-failing tests in open security branches since it is important to be able to run the tests successfully before releasing.

Commits to security branches are to be coordinated with the release manager for the corresponding feature version, as listed in the Status of Python versions. Merging of pull requests to security branches is restricted to release managers. Any release made from a security branch is source-only and done only when actual security fixes have been applied to the branch. These releases have a micro version number greater than the last bugfix release.

End-of-life branches¶

The code base for a release cycle which has reached end-of-life status is frozen and no longer has a branch in the repo. The final state of the end-of-lifed branch is recorded as a tag with the same name as the former branch, for example, 3.8 or 2.7.

The Status of Python versions page contains list of active and end-of-life branches.

The latest release for each Python version can be found on the download page.

Pre-alpha¶

The branch is in this stage when no official release has been done since the latest final release. There are no special restrictions placed on commits, although the usual advice applies (getting pull requests reviewed, avoiding breaking the buildbots).

Alpha¶

Alpha releases typically serve as a reminder to the core team that they need to start getting in changes that change semantics or add something to Python as such things should not be added during a Beta. Otherwise no new restrictions are in place while in alpha.

Beta¶

After a first beta release is published, no new features are accepted. Only bug fixes and improvements to documentation and tests can now be committed. This is when the core team should concentrate on the task of fixing regressions and other new issues filed by users who have downloaded the alpha and beta releases.

Being in beta can be viewed much like being in RC but without the extra overhead of needing commit reviews.

Release Candidate (RC)¶

A branch preparing for an RC release can only have bugfixes applied that have been reviewed by other core team members. Generally, these issues must be severe enough (for example, crashes) that they deserve fixing before the final release. All other issues should be deferred to the next development cycle, since stability is the strongest concern at this point.

While the goal is to have no code changes between an RC and a final release, there may be a need for final documentation or test fixes. Any such proposed changes should be discussed first with the release manager.

You cannot skip the peer review during an RC, no matter how small! Even if it is a simple copy-and-paste change, everything requires peer review from a core team member.

Final¶

When a final release is being cut, only the release manager (RM) can make changes to the branch.