The responsibilities of a core team member shift based on what kind of branch of Python a developer is working on and what stage the branch is in.
To clarify terminology, Python uses a major.minor.micro nomenclature for production-ready releases. So for Python 3.1.2 final, that is a major version of 3, a minor version of 1, and a micro version of 2.
new major versions are exceptional; they only come when strongly incompatible changes are deemed necessary, and are planned very long in advance;
new minor versions are feature releases; they get released annually, from the current
branch;
new micro versions are bugfix releases; they get released roughly every 2 months; they are prepared in
branches.
We also publish non-final versions which get an additional qualifier:
,
,
. These versions are aimed at testing by advanced users, not production use.
Each release of Python is tagged in the source repo with a tag of the form vX.Y.ZTN, where X is the major version, Y is the minor version, Z is the micro version, T is the release level (a for alpha releases, b for beta, rc release candidate, and null for final releases), and N is the release serial number. Some examples of release tags: v3.7.0a1, v3.6.3, v2.7.14rc1.
Branches
There is a branch for each feature version, whether released or not (for example, 3.12, 3.13).
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
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
or
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
rather than the
.
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
, 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
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
. 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
page contains list of active and end-of-life branches.
The latest release for each Python version can be found on the
.
Stages
Based on what stage the
version of Python is in, the responsibilities of a core team member change in regards to commits to the VCS (version control system).
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
. 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
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.
Repository administration
The source code is currently hosted on
in the
.
Organization repository policy
Within the
, repositories are expected to relate to the Python language, the CPython reference implementation, their documentation and their development workflow. This includes, for example:
The reference implementation of Python and related repositories:
.
Tooling and support around CPython development:
,
.
Helpers and backports for Python/CPython features:
,
,
,
.
Organization-related repositories: the
,
.
Documentation and websites for all the above:
,
,
, docs translations.
Infrastructure for all the above:
,
.
Discussions and notes around official development-related processes and events:
,
.
Before adding a new repository to the organization, open a discussion to seek consensus in the
. Once people are satisfied with that, ask the
to grant permission. Note that this process is not necessary for
following
, which can be added at a core team member’s discretion.
Note that several repositories remain in the organization for historic reasons, and would probably not be appropriate to add today.
Generally, new repositories should start their life under personal GitHub accounts or other GitHub orgs. It is relatively easy to move a repository to the organization once it is mature. For example, this would now apply to experimental features like
,
, and drafts of new guides and other documentation (for example,
).
General-use tools and libraries (for example,
or
) should also be developed outside the python organization, unless core devs (as represented by the SC) specifically want to “bless” one implementation (as with
,
, or
).
Organization owner policy
The GitHub Organization Owner role allows for full management of all aspects of the Python organization. Allowing for visibility and management of all aspects at all levels including organization membership, team membership, access control, and merge privileges on all repositories. For full details of the permission levels see
GitHub’s documentation on Organization permission levels
. This role is paramount to the security of the Python Language, Community, and Infrastructure.
The Executive Director of the Python Software Foundation delegates authority on GitHub Organization Owner Status to Jacob Coffee - Python Software Foundation Infrastructure Engineer. Common reasons for this role are: Infrastructure Staff Membership, Python Software Foundation General Counsel, and Python Software Foundation Staff as fallback.
Inactive or unreachable members may be removed with or without notice. Members who no longer necessitate this level of access will be removed with notice.
Multi-Factor Authentication must be enabled by the user in order to remain an Owner of the Python Organization.
Current owners
Name
Role
GitHub Username
Benjamin Peterson
Infrastructure Staff
benjaminp
Noah Kantrowitz
Infrastructure Staff
coderanger
Donald Stufft
Infrastructure Staff
dstufft
Ee Durbin
Infrastructure Staff
ewdurbin
Jacob Coffee
PSF Infrastructure Engineer
JacobCoffee
Petr Viktorin
CPython Developer in Residence
encukou
Łukasz Langa
ambv
Certain actions (blocking spam accounts, inviting new users, adjusting organization-level settings) can only
by owners of the Python organization on GitHub. The
team can be mentioned to request assistance from an organization owner.
Repository administrator role policy
The Administrator role on the repository allows for managing all aspects including collaborators, access control, integrations, webhooks, and branch protection. For full details of the permission levels see
GitHub’s documentation on repository permission levels
. Common reasons for this role are: maintenance of core workflow tooling, Release Managers for all
,
, and
releases, and additional Python core team members as necessary for redundancy. Occasional temporary administrator access is acceptable as necessary for core workflow projects.
Inactive or unreachable members may be removed with or without notice. Members who no longer necessitate this level of access will be removed with notice.
Multi-Factor Authentication must be enabled by the user in order to remain an Administrator of the repository.
Current administrators
Name
Role
GitHub Username
Savannah Ostrowski
Python 3.16 and 3.17 Release Manager
savannahostrowski
Hugo van Kemenade
Python 3.14 and 3.15 Release Manager
hugovk
Thomas Wouters
Python 3.12 and 3.13 Release Manager
Yhg1s
Pablo Galindo
Python 3.10 and 3.11 Release Manager, Maintainer of buildbot.python.org
pablogsal
Łukasz Langa
ambv
Brett Cannon
brettcannon
Ezio Melotti
Maintainer of bugs.python.org GitHub webhook integration
ezio-melotti
Mariatta Wijaya
Maintainer of bedevere, blurb_it and miss-islington
Mariatta
Seth Larson
PSF Security Developer-in-Residence
sethmlarson
Petr Viktorin
CPython Developer in Residence
encukou
Repository release manager role policy
Release Managers for
,
, and
Python releases are granted Administrator privileges on the repository. Once a release branch has entered
, the Release Manager for that branch creates a final tag and deletes the branch. After this, they are removed as an Administrator.
Multi-Factor Authentication must be enabled by the user in order to retain access as a Release Manager of the branch.
PyPI organization policy
The Python core team owns the
and
organizations on PyPI for publishing packages. The main benefits of adding packages to these organizations:
Visibility: we can see our packages under a PyPI org page
Maintainability: we can share granular PyPI access to improve the bus factor
The general policy on which organization to use:
: for development tools that are tied fairly closely to CPython development. For example,
and
. Users generally shouldn’t have to care except for developing CPython itself (although that doesn’t mean the tools necessarily have to be unusable for anyone else).
: for general-audience projects that are maintained by the Python core team. For example,
,
and
.
Governance
The Python Steering Council has overall authority over Python and has delegated some of its responsibilities to other groups.
This table lists the PEPs defining each group’s responsibilities, and the repository where you can open an issue to ask for a decision.
Name
PEP
Contact repo
Steering Council
C API Working Group
Documentation Editorial Board
Typing Council