In-development (main) branch¶

Themain branch is the branch for the next feature release; it isunder active development for all kinds of changes: new features, semanticchanges, performance improvements, bug fixes.

At some point during the life-cycle of a release, anewmaintenance branch is created to host all bug fixingactivity for further micro versions in a feature version (3.12.1, 3.12.2, and soon).

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

Maintenance branches¶

A branch for a previous feature release, currently being maintained for bugfixes, or for the next feature release in itsbeta orrelease candidate stages.There is usually either one or two maintenance branches at any given time forPython 3.x. After the final release of a new minor version (3.x.0), releasesproduced from a maintenance branch are calledbugfix ormaintenancereleases; the terms are used interchangeably. These releases have amicro version number greater than zero.

The only changes allowed to occur in a maintenance branch without debate arebug fixes, test improvements, and edits to the documentation.Also, a general rule for maintenance branches is that compatibilitymust 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 andmust bediscussed first.

Backporting changes reduces the risk of future conflicts.For documentation, it increases the visibility of improvements,since most readers access thestable documentationrather than thedevelopment documentation.

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

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

Security branches¶

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

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

Commits to security branches are to be coordinated with the release managerfor the corresponding feature version, as listed in theStatus 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 actualsecurity fixes have been applied to the branch. These releases have amicro version number greater than the lastbugfix release.

End-of-life branches¶

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

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

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

Pre-alpha¶

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

Alpha¶

Alpha releases typically serve as a reminder to core developers that theyneed to start getting in changes that change semantics or add something toPython as such things should not be added during aBeta. Otherwise no newrestrictions are in place while in alpha.

Beta¶

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

Being in beta can be viewed much like being inRC but without the extraoverhead of needing commit reviews.

Release Candidate (RC)¶

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

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

Youcannot skip the peer review during an RC, no matter how small! Even ifit is a simple copy-and-paste change,everything requires peer review froma core developer.

Final¶

When a final release is being cut, only the release manager (RM) can makechanges to the branch. After the final release is published, the fulldevelopment cycle starts again for the next minor version.

Organization repository policy¶

Within theGitHub Python organization,repositories are expected to relate to the Python language, the CPythonreference implementation, their documentation and their development workflow.This includes, for example:

• The reference implementation of Python and related repositories:CPython.

• Tooling and support around CPython development:pyperformance,Bedevere.

• Helpers and backports for Python/CPython features:typing_extensions,typeshed,tzdata,pythoncapi-compat.

• Organization-related repositories: theCode of Conduct,.github.

• Documentation and websites for all the above:python.org repository,PEPs,Devguide, docs translations.

• Infrastructure for all the above:docsbuild-scripts,buildmaster-config.

• Discussions and notes around official development-related processes and events:steering-council,core-sprint.

Before adding a new repository to the organization, open a discussion to seek consensusin theCommitters Discourse category.Once people are satisfied with that, ask thePython steering councilto grant permission.

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 GitHubaccounts or other GitHub orgs. It is relatively easy to move a repository tothe organization once it is mature. For example, this would now apply toexperimental features likeasyncio,exceptiongroups,and drafts of new guides and other documentation (for example,redistributor-guide).

General-use tools and libraries (for example,mypyorBlack) should also be developed outsidethepython organization, unless core devs (as represented by the SC)specifically want to “bless” one implementation (as withtypeshed,tzdata, orpythoncapi-compat).

Organization owner policy¶

The GitHub Organization Owner role allows for full management of all aspects ofthe Python organization. Allowing for visibility and management of all aspectsat all levels including organization membership, team membership, accesscontrol, and merge privileges on all repositories. For full details of thepermission levels seeGitHub’s documentation on Organization permissionlevels.This role is paramount to the security of the Python Language, Community, andInfrastructure.

The Executive Director of the Python Software Foundation delegates authority onGitHub Organization Owner Status to Ee Durbin - Python SoftwareFoundation Director of Infrastructure. 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. Memberswho 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 anOwner of the Python Organization.

Current owners¶

Certain actions (blocking spam accounts, inviting new users, adjustingorganization-level settings) can onlybe performed by owners of the Pythonorganization on GitHub. The@python/organization-owners team can bementioned to request assistance from an organization owner.

Repository administrator role policy¶

The Administrator role on the repository allows for managing all aspectsincluding collaborators, access control, integrations, webhooks, and branchprotection. For full details of the permission levels seeGitHub’sdocumentation on repository permission levels.Common reasons for this role are: maintenance of Core DeveloperWorkflow tooling, Release Managers for allin-development,maintenance, andsecurity modereleases, and additional Python Core Developers as necessary for redundancy.Occasional temporary administrator access is acceptable as necessary for CoreDeveloper workflow projects.

Inactive or unreachable members may be removed with or without notice. Memberswho 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 anAdministrator of the repository.

Current administrators¶

Repository release manager role policy¶

Release Managers forin-development,maintenance, andsecurity mode Python releases aregranted Administrator privileges on the repository. Once a release branch hasenteredend-of-life, the Release Manager for that branchcreates a final tag and deletes the branch. After this, they areremoved as an Administrator.

Multi-Factor Authentication must be enabled by the user in order to retainaccess as a Release Manager of the branch.

PyPI organization policy¶

The Python core team owns thecpython andpythonorganizations 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:

• cpython:for development tools that are tied fairly closely to CPython development.For example,blurb andcherry-picker.Users generally shouldn’t have to care except for developing CPython itself(although that doesn’t mean the tools necessarily have to be unusable foranyone else).

• python:for general-audience projects that are maintained by the Python core team.For example,pyperformance,python-docs-theme andtzdata.