In each of the 2.x and 3.x realms, the branch for a feature version is always a
descendant of the previous feature version: for example, the 3.3 branch is a
descendant of the 3.2 branch.
17.1.1. In-development (main) branch
The default 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. As the name indicates, it
is the branch checked out by default by Mercurial.
Once a Final release (say, 3.3) is made from the in-development branch, a
new maintenance branch is created to host all bug fixing
activity for further micro versions (3.3.1, 3.3.2, etc.).
17.1.2. Maintenance branches
A branch for a previous feature release, currently being maintained for bug
fixes. There are usually two maintenance branches at any given time: one for
Python 3.x and
one for Python 2.x. At some point in the future, Python 2.x will be closed
for bug fixes and there will be only one maintenance branch left.
The only changes allowed to occur in a maintenance branch without debate are
bug fixes. Also, a general rule for maintenance branches is that compatibility
must not be broken at any point between sibling minor releases (3.3.1, 3.3.2,
etc.). For both rules, only rare exceptions are accepted and must be
Sometime after a new maintenance branch is created (after a new minor version
is released), the old maintenance branch on that major version will go into
usually after one last maintenance release at the discretion of the
release manager. For example, the 3.2 maintenance branch was put into
security mode after the 3.2.4 final maintenance release
following the release of 3.3.0.
17.1.3. Security branches
A branch less than 5 years old but no longer in maintenance mode.
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.
Commits to security branches are to be coordinated with the release manager
for the corresponding feature version, as listed below in the Summary.
Any release made from a security branch is source-only and done only when actual
security patches have been applied to the branch.