开发周期¶
核心开发者的职责会根据 Python 开发者正在处理的 Python 分支类型以及分支所处的阶段而变化。
为了阐明术语，Python 使用 major.minor.micro 命名法来表示可用于生产的版本。因此，对于 Python 3.1.2 最终版本，其主版本为 3，次版本为 1，微版本为 2。
新的主版本是例外；它们仅在被认为需要强烈不兼容的更改时才会出现，并且会提前很长时间进行规划；
新的次版本是功能版本；它们每年从当前的 正在开发中 分支中发布；
新的微版本是错误修复版本；它们大约每 2 个月发布一次；它们在 维护 分支中准备。
我们还会发布非最终版本，这些版本会获得额外的限定符：Alpha、Beta、候选版本。这些版本旨在由高级用户进行测试，而不是用于生产。
Python 的每个版本都会在源代码存储库中标记为 vX.Y.ZTN 形式的标签，其中 X 是主版本，Y 是次版本，Z 是微版本，T 是发布级别（a 表示 Alpha 版本，b 表示 Beta 版本，rc 表示候选版本，null 表示最终版本），N 是发布序列号。一些发布标签示例：v3.7.0a1、v3.6.3、v2.7.14rc1。
分支¶
对于每个功能版本都有一个分支，无论是否已发布（例如 3.7、3.8）。
正在开发中（主）分支¶
main 分支是下一个功能版本的开发分支；它正积极开发各种更改：新功能、语义更改、性能改进、错误修复。
在某个发布的生命周期中，会创建一个新的 维护分支 来承载功能版本中后续微版本的所有错误修复活动（3.8.1、3.8.2 等）。
对于 3.4 及更早版本，通常在最终版本发布时完成此操作（例如，3.4.0 最终版）。
从 3.5 版本开始，我们在进入 Beta 阶段（3.5.0 Beta 1）时创建发布维护分支（例如 3.5）。这允许在主分支中进行版本 3.n+1 的功能开发，同时进行版本 3.n 的 Beta 和候选版本稳定期。
维护分支¶
用于以前的功能版本的分支，当前正在维护以进行错误修复，或用于其 Beta 或 候选版本 阶段中的下一个功能版本。对于 Python 3.x，任何时候通常都有一个或两个维护分支。在新次版本的最终版本（3.x.0）发布后，从维护分支中产生的版本称为错误修复或维护版本；这些术语可以互换使用。这些版本的微版本号大于零。
在维护分支中唯一允许在不经过讨论的情况下进行的更改是错误修复、测试改进和文档编辑。此外，维护分支的一般规则是，在兄弟小版本发布（3.5.1、3.5.2 等）之间，兼容性不得在任何时候中断。对于这两个规则，仅接受罕见的例外，并且必须首先进行讨论。
回传更改可降低未来冲突的风险。对于文档，它提高了改进的可见性，因为大多数读者访问的是稳定文档，而不是开发文档。
通常在下一个功能发布周期达到功能冻结时（即在其第一个测试版预发布时）创建一个新的维护分支。从那时起，针对剩余预发布、最终发布（3.x.0）和后续错误修复发布的更改将合并到该维护分支中。
在最终发布（3.x.0）后的某个时间，前一个次要版本的维护分支将进入安全模式，通常在发布经理自行决定至少再发布一次错误修复后。例如，在发布 3.5.1 后发布了 3.4.4 错误修复后，3.4 维护分支被置于安全模式。
安全分支¶
一个年龄小于 5 年但不再处于错误修复模式的分支是一个安全分支。
对安全分支进行的唯一更改是修复攻击者可利用的问题，例如崩溃、权限提升以及其他问题（例如拒绝服务攻击）。任何其他更改不被视为安全风险，因此不会回传到安全分支。你还应该考虑修复开放安全分支中的硬故障测试，因为在发布之前能够成功运行测试非常重要。
提交到安全分支应与相应功能版本的发布经理协调，如Python 版本状态中所列。将拉取请求合并到安全分支的操作仅限于发布经理。从安全分支进行的任何发布都是仅源代码的，并且仅在实际安全补丁已应用于该分支时进行。这些发布的微版本号大于上一个错误修复版本。
生命周期结束分支¶
已达到生命周期结束状态的发布周期的代码库已冻结，并且在仓库中不再有分支。生命周期结束分支的最终状态被记录为一个标记，其名称与前分支相同，例如 3.3 或 2.6。
Python 版本状态页面包含活动分支和生命周期结束分支的列表。
可以在下载页面上找到每个 Python 版本的最新版本。
阶段¶
根据正在开发中版本的 Python 处于哪个阶段，核心开发人员的责任会随着对VCS的提交而改变。
Pre-alpha¶
当自最新最终发布以来没有进行任何官方发布时，分支处于此阶段。对提交没有特殊限制，尽管适用通常的建议（获取补丁审查，避免破坏构建机器人）。
Alpha¶
Alpha 版本通常提醒核心开发人员，他们需要开始进行更改语义或向 Python 添加内容的更改，因为在Beta期间不应添加此类内容。否则，在 alpha 阶段没有新的限制。
Beta¶
在发布第一个 Beta 版本后，不再接受新功能。现在只能提交错误修复以及对文档和测试的改进。此时，核心开发人员应集中精力修复回归和其他新问题，这些问题是由下载了 Alpha 和 Beta 版本的用户提交的。
处于 Beta 阶段可以被视为处于RC阶段，但没有需要提交审查的额外开销。
请参阅上面正在开发中（主）分支部分中的注释，了解有关在 Beta 期间创建 3.5 维护分支的新信息。
候选版本 (RC)¶
准备 RC 版本的分支只能应用其他核心开发人员已审查的错误修复。通常，这些问题必须足够严重（例如崩溃），以至于需要在最终版本发布之前进行修复。所有其他问题都应推迟到下一个开发周期，因为此时稳定性是最重要的考虑因素。
虽然目标是在 RC 版本和最终版本之间没有代码更改，但可能需要最终文档或测试修复。任何此类提议的更改都应首先与版本管理器讨论。
在 RC 期间，不能跳过同行评审，无论多么小！即使是一个简单的复制粘贴更改，所有内容都需要核心开发人员的同行评审。
最终¶
当最终版本被切断时，只有版本管理器 (RM) 可以对分支进行更改。最终版本发布后，完整的开发周期将再次开始下一个次要版本。
存储库管理¶
组织存储库策略¶
在GitHub Python 组织中，存储库应与 Python 语言、CPython 参考实现、其文档及其开发工作流相关。例如，这包括
Python 和相关存储库的参考实现（即CPython）
围绕 CPython 开发的工具和支持（例如pyperformance、Bedevere）
Python/CPython 特性的帮助程序和反向移植（例如typing_extensions、typeshed、tzdata、pythoncapi-compat）
上述所有内容的文档和网站（例如python.org 存储库、PEPs、Devguide、文档翻译）
上述所有内容的基础设施（例如docsbuild-scripts、buildmaster-config）
围绕官方开发相关流程和事件的讨论和笔记（例如steering-council、core-sprint）
在向组织添加新存储库之前，请在提交者 Discourse 类别中展开讨论以寻求共识。一旦人们对此感到满意，请要求Python 指导委员会授予许可。
请注意，由于历史原因，几个存储库仍然保留在组织中，并且今天可能不适合添加。
通常，新存储库应该在个人 GitHub 帐户或其他 GitHub 组织下开始其生命周期。一旦存储库成熟，将其移动到组织中相对容易。例如，这现在适用于asyncio、exceptiongroups等实验性功能，以及新指南和其他文档的草稿（例如redistributor-guide）。
通用工具和库（例如mypy或Black）也应在python组织外部开发，除非核心开发人员（由 SC 代表）特别希望“认可”一个实现（例如typeshed、tzdata或pythoncapi-compat）。
组织所有者策略¶
GitHub 组织所有者角色允许完全管理 Python 组织的所有方面。允许查看和管理所有级别的所有方面，包括组织成员资格、团队成员资格、访问控制和所有存储库上的合并权限。有关权限级别的完整详细信息，请参阅GitHub 关于组织权限级别的文档。此角色对 Python 语言、社区和基础设施的安全至关重要。
Python 软件基金会执行董事将 GitHub 组织所有者状态的权限委派给 Ee Durbin - Python 软件基金会基础设施总监。此角色的常见原因包括：基础设施工作人员成员、Python 软件基金会总法律顾问和 Python 软件基金会工作人员作为后备。
不活跃或无法联系的成员可能会在有或没有通知的情况下被移除。不再需要此访问级别的成员将收到通知后被移除。
用户必须启用多重身份验证才能继续成为 Python 组织的所有者。
当前所有者¶
姓名 |
角色 |
GitHub 用户名 |
|---|---|---|
Benjamin Peterson |
基础设施工作人员 |
benjaminp |
Noah Kantrowitz |
基础设施工作人员 |
coderanger |
Donald Stufft |
基础设施工作人员 |
dstufft |
Ee Durbin |
PSF 基础设施总监 |
ewdurbin |
Van Lindberg |
PSF 总法律顾问 |
VanL |
Łukasz Langa |
CPython 驻场开发者 |
ambv |
某些操作（阻止垃圾邮件帐户、邀请新用户、调整组织级别设置）只能 由 GitHub 上 Python 组织的所有者执行。可以提及 @python/organization-owners 团队，请求组织所有者提供帮助。
存储库管理员角色策略¶
存储库上的管理员角色允许管理所有方面，包括协作者、访问控制、集成、Webhook 和分支保护。有关权限级别的详细信息，请参阅 GitHub 关于存储库权限级别的文档。此角色的常见原因包括：维护核心开发者工作流工具、所有 正在开发中、维护 和 安全模式 版本的版本管理器以及其他 Python 核心开发者（如有必要，以实现冗余）。对于核心开发者工作流项目，偶尔的临时管理员访问权限是可以接受的。
不活跃或无法联系的成员可能会在有或没有通知的情况下被移除。不再需要此访问级别的成员将收到通知后被移除。
用户必须启用多重身份验证才能继续成为存储库的管理员。
当前管理员¶
姓名 |
角色 |
GitHub 用户名 |
|---|---|---|
Hugo van Kemenade |
Python 3.14 和 3.15 版本管理器 |
hugovk |
Thomas Wouters |
Python 3.12 和 3.13 版本管理器 |
Yhg1s |
Pablo Galindo |
Python 3.10 和 3.11 版本管理器，buildbot.python.org 的维护者 |
pablogsal |
Łukasz Langa |
Python 3.8 和 3.9 版本管理器，PSF CPython 2021 年至今驻场开发者 |
ambv |
Brett Cannon |
brettcannon |
|
Ezio Melotti |
bugs.python.org GitHub Webhook 集成的维护者 |
ezio-melotti |
Mariatta Wijaya |
bedevere、blurb_it 和 miss-islington 的维护者 |
Mariatta |
存储库版本管理器角色策略¶
正在开发中、维护 和 安全模式 Python 版本的版本管理器在存储库上获得管理员权限。一旦某个版本分支进入 生命周期结束，该分支的版本管理器将被移除管理员权限，并被授予合并该分支更改的唯一权限（存储库管理员除外）。
用户必须启用多重身份验证才能保留作为分支版本管理器的访问权限。
治理¶
Python 指导委员会对 Python 拥有全面权限，并已将部分职责委托给其他小组。
此表列出了定义每个小组职责的 PEP，以及可以打开问题以请求决策的存储库。
姓名 |
PEP |
联系存储库 |
|---|---|---|
指导委员会 |
||
C API 工作组 |
||
文档编辑委员会 |
||
类型化委员会 |
另请参阅