Python核心团队承压维护七大分支 建议新项目首选次新版本

每个python版本，从何而起，又因何而终？ — 码农高天

码农高天

针对 Python 五年生命周期内新旧重合的维护现状，新立项应用应优先采用次新版本或等待最新版本更新至两到三个修订号，以在规避早期边缘瑕疵的同时兼顾前沿特性与性能收益。

AI-assisted summary of 每个python版本，从何而起，又因何而终？ — original source. Check the original for full context.

Source published:

Key ideas

  • Python 每个新版本的完整开发与维护周期约为六年半，其中历时约 17 个月从立项走完 Alpha、Beta Freeze 和 RC 测试并发布 .0 正式版，随后享受为期 5 年的官方支持。 (0:00)
  • 自 Python 3.13 起，官方正式将 Bug Fix 维护阶段从原本的一年半延长至整整两年，随后接续 3 年的 Security Fix 阶段，直至 5 年寿命到期（EOL）。 (1:48)
  • 由于版本周期重叠，以志愿奉献为主的 Python 核心开发团队在任何时间点都需要并行维护 6 至 7 个版本分支，在生态升级成本与版本碎片化之间保持权衡。 (1:48)
  • 针对新项目选型，码农高天建议优先考虑正式版中“第二新”的版本，或等待最新版迭代至 .2 或 .3 修订版后再接入，在系统稳定性与前沿特性间取得平衡。 (5:00)

Detailed notes

## Background 该视频由开发者“码农高天”于 2025 年 5 月 9 日发布在 YouTube 平台。根据视频简介，本期内容旨在系统介绍 Python 每个版本的生命周期，帮助开发者对 Python 的版本发布机制形成更加清晰的概念。

## TL;DR 视频全面梳理了 Python 版本从启动开发到彻底退役的完整周期。每个版本历经约 17 个月的开发与测试，在经历每月的 Alpha 迭代、次年 5 月特性锁定的 Beta Freeze 以及高稳定要求的 RC 阶段后，于 10 月正式推出；发布后则进入为期 5 年的官方支持，涵盖 2 年的 Bug 修复期与 3 年的安全维护期直至最终 EOL。针对核心团队需同时维护 6 至 7 个重叠分支的现实与开发者的版本焦虑，作者给出了新项目选型的实用策略：优先考虑已兼顾稳定性的“次新”版本，或在最新版本迭代至 .2/.3 补丁包后接入，亦可根据 3.11 等关键性能跃升特性果断升级。

## Atmosphere & style 全片节奏从容清晰，兼具工程架构的严谨度与开源社区内部视角的生动趣味。博主以亲历者口吻娓娓道来，既有对发布规范与分支维护压力的客观剖析，又穿插了“核心开发者也有拖延症、卡着 Beta Freeze 抢交特性”的幽默调侃。观看体验既像是一堂干货扎实的开源工程管理公开课，又像是在听技术同行分享务实接地气的技术选型心法。

## Bulletin - [00:00](https://www.youtube.com/watch?v=wgfZpqJqX9Y&t=0s) Python 每个新版本的完整开发与维护周期约为六年半，其中历时约 17 个月从立项走完 Alpha、Beta Freeze 和 RC 测试并发布 .0 正式版，随后享受为期 5 年的官方支持。 - [01:48](https://www.youtube.com/watch?v=wgfZpqJqX9Y&t=108s) 自 Python 3.13 起，官方正式将 Bug Fix 维护阶段从原本的一年半延长至整整两年，随后接续 3 年的 Security Fix 阶段，直至 5 年寿命到期（EOL）。 - [01:48](https://www.youtube.com/watch?v=wgfZpqJqX9Y&t=108s) 由于版本周期重叠，以志愿奉献为主的 Python 核心开发团队在任何时间点都需要并行维护 6 至 7 个版本分支，在生态升级成本与版本碎片化之间保持权衡。 - [05:00](https://www.youtube.com/watch?v=wgfZpqJqX9Y&t=300s) 针对新项目选型，码农高天建议优先考虑正式版中“第二新”的版本，或等待最新版迭代至 .2 或 .3 修订版后再接入，在系统稳定性与前沿特性间取得平衡。

## Key takeaways - [00:00](https://www.youtube.com/watch?v=wgfZpqJqX9Y&t=0s) Python 拥有高度标准化的发布流程，每个版本配备专职 Release Manager（通常一人连管两个版本），并通过提交 PEP 明确固化各项发布时间节点。 - [00:00](https://www.youtube.com/watch?v=wgfZpqJqX9Y&t=0s) 新版本每年 5 月在 main 分支启动开发，当年 10 月发布首个供尝鲜与收集反馈的 Alpha 1 版本，此后每月发布一个 Alpha 版本直至次年 5 月。 - [00:00](https://www.youtube.com/watch?v=wgfZpqJqX9Y&t=0s) 次年 5 月的 Beta Freeze 是关键分水岭，该节点会拉出版本专属分支并彻底截止新特性开发，后续只允许合入 Bug Fix，剩余新特性继续留在 main 分支流向下一版本。 - [00:00](https://www.youtube.com/watch?v=wgfZpqJqX9Y&t=0s) Beta Freeze 前的数周是核心开发者赶工期的高峰，许多关键功能（例如去年的新 REPL）都是卡在此节点前合并入库。 - [01:48](https://www.youtube.com/watch?v=wgfZpqJqX9Y&t=108s) Beta 阶段持续约 3 个月，主要供下游重要开源项目跟进测试兼容性；随后的 RC 阶段则以严苛的“稳定性压倒一切”为原则，严格审查 backport 是否存在副作用。 - [01:48](https://www.youtube.com/watch?v=wgfZpqJqX9Y&t=108s) 历经至少两个 RC 版本的打磨后，Python 官方通常会在 10 月正式推出 .0 版本，整个研发准备期历时约 17 个月。 - [01:48](https://www.youtube.com/watch?v=wgfZpqJqX9Y&t=108s) 正式版上线后进入 5 年官方支持期：前 2 年为 Bug Fix 阶段（约每两个月发布一次修订版），后 3 年转入仅针对高危漏洞的 Security Fix 阶段，最终进入 EOL 完全终止支持。 - [01:48](https://www.youtube.com/watch?v=wgfZpqJqX9Y&t=108s) 核心团队需要长期同时维护 6 到 7 个不同版本的分支，在避免普通用户过于频繁升级生产环境与防止老旧版本积重难返之间面临平衡挑战。 - [05:00](https://www.youtube.com/watch?v=wgfZpqJqX9Y&t=300s) 在实际工程项目选型上，建议新起项目优先使用正式版中的“次新版”（如 3.13 推出时选 3.12），以避开最新大版本初期的边缘缺陷。 - [05:00](https://www.youtube.com/watch?v=wgfZpqJqX9Y&t=300s) 若要直接采纳最新大版本，通常推荐等待其小版本迭代至 .2 或 .3 之后，此时系统稳定性已在生产环境中得到充分验证。 - [05:00](https://www.youtube.com/watch?v=wgfZpqJqX9Y&t=300s) 对于提供重大收益的核心特性（如 Python 3.11 带来的显著性能提升），开发者应根据业务瓶颈积极规划、主动向新版本迁移。

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=wgfZpqJqX9Y&t=0s) Python 版本生命周期：从开发、Alpha 到 Beta Freeze

随着 Python 3.14 的 Beta 版本正式发布，主分支（`main` branch）上的 3.15 开发工作也随之拉开序幕。作为一个拥有数百万开发者使用的超大型开源项目，Python 拥有一套高度固定且规范的版本生命周期管理机制。每个 Python 版本都会由专门指定的 Release Manager 统筹负责所有与发布相关的事务，通常一位 Release Manager 会连续负责两个版本。在版本启动初期，Release Manager 会提交一份专门的 PEP（Python Enhancement Proposal），详细列出该版本预期的各个发布时间节点。近几年来，这一开发与发布节奏已基本形成固定规律：每年 5 月份，前一个版本会拉出专属的分支，新版本的开发便在 `main` 分支上正式起步。

从 5 月份启动开发，到同年的 10 月份，官方会发布该版本的第一个 Alpha 版本（Alpha 1）。这是官方发布的第一个可供下载安装的测试版本，但其内部特性随时可能发生变动，主要面向乐于尝鲜的用户进行试用并收集社区反馈。从 Alpha 1 开始直至次年 5 月，团队基本每个月都会发布一个新的 Alpha 版本，整个过程持续在 `main` 分支上直接迭代。到了次年 5 月，团队会正式为该版本建立独立的分支，这一关键节点被称为“Beta Freeze”。

```mermaid flowchart TD accTitle: Python 版本开发生命周期 accDescr: 展示 Python 版本从 main 分支开发、Alpha 阶段、Beta Freeze、RC 阶段到正式发布的流程。

subgraph Dev ["开发与测试阶段（约17个月）"] A["5月：main 分支开始开发"] --> B["10月：发布首个 Alpha 版本"] B --> C["次年5月：建立专属分支<br/>（Beta Freeze）"] C --> D["Beta 阶段（持续约3个月）<br/>只修 Bug，下游生态开始兼容测试"] D --> E["RC 阶段（Release Candidate）<br/>稳定性优先，发布2-3个版本"] end

subgraph Maintenance ["发布与维护阶段（5年官方支持）"] E --> F["10月：发布.0 正式版"] F --> G["Bug Fix 阶段（为期 2 年）<br/>约每 2 个月发布一次修订版"] G --> H["Security Fix 阶段（为期 3 年）<br/>仅修复安全漏洞"] H --> I["EOL（End of Life）<br/>完全停止官方支持"] end ```

Beta Freeze 标志着该版本所有新功能的开发彻底截止，同时发布首个 Beta 版本。Beta 版本的稳定性显著高于 Alpha，社区中体量较大、使用较广的第三方开源项目通常会在此阶段跟进，测试自身的项目能否在新版本上正常跑通。码农高天透露，Beta Freeze 之前的几周往往是整个 Python 社区活跃度最高的一段时期，大家都在赶工加码，他调侃道：“Core Dev 也是有拖延症的，有不少新功能都是卡着 Beta Freeze 的节点闷进去的，比如去年的新的 REPL。”进入 Beta Freeze 之后，该版本的专属分支便不再接纳任何新特性，仅允许 Bug Fix 提交；而所有后续新特性的开发则继续留在 `main` 分支，进入再下一个版本的开发周期。

- **Release Manager 机制**：每个版本配备专职负责人，单人通常覆盖两个版本，并以 PEP 形式固化发布路线图。 - **开发与 Alpha 周期**：5 月立项，10 月出 Alpha 1，此后每月发布一个 Alpha 版本直至次年 5 月。 - **Beta Freeze 节点**：锁定特性开发，建立版本专属分支，杜绝新特性合并入该分支。

---

[01:48](https://www.youtube.com/watch?v=wgfZpqJqX9Y&t=108s) 从 RC 到正式版发布与 5 年官方支持周期

Beta 阶段通常会持续 3 个月左右，随后进入发布候选阶段，即 RC（Release Candidate）。RC 与 Beta 在本质上虽然类似，但对代码稳定性的要求上升到了极其严苛的程度。此时核心团队在审查反向移植（backport）的 Bug 修复时会格外挑剔，必须深入评估每一个修复是否会带来潜在的副作用（side effects）进而破坏其他功能，真正做到“稳定性压倒一切”，为首个正式版发布扫清障碍。RC 阶段通常至少发布两个版本，视社区实际反馈决定是否追加第三个 RC，最终在 10 月份左右推出 `.0` 正式版本。从最初立项开发到正式发布，整个周期历时大约 17 个月。

正式版上线后，该版本便进入了漫长的维护期，官方支持总时长为 5 年： 1. **Bug Fix 阶段（2 年）**：持续修复代码缺陷，大约每两个月发布一个微版本。码农高天指出，在 Python 3.12 之前，Bug Fix 阶段的时间略短，大约为一年半，自 Python 3.13 起该阶段正式调整延长至整整两年。 2. **Security Fix 阶段（3 年）**：两年 Bug Fix 期结束后，普通 Bug 将不再进行修复，团队仅针对与安全相关的高危漏洞提供安全补丁。 3. **EOL（End of Life）**：满 5 年之后，该版本正式走向生命周期的终点，官方不再提供任何更新。

由于各版本生命周期重叠，如果将当前所有受支持的版本叠加，Python 核心团队需要同时维护 6 到 7 个版本的分支。码农高天感叹：“从图里大家应该能看出来，Python 的团队要同时维护 6 到 7 个版本，对于一个几乎完全是为爱发电的团队来说，其实还是有不小压力的。”任何编程语言的设计团队都面临着类似的权衡难题：维护期过短，普通用户就需要过于频繁地升级生产环境；维护期过长，又有过多用户长期驻留在陈旧版本，导致新特性难以普及，遗留的历史包袱积重难返。

---

[05:00](https://www.youtube.com/watch?v=wgfZpqJqX9Y&t=300s) 开发者该如何选择 Python 版本？

了解版本的生命周期，有助于开发者在规划自己的业务系统与应用架构时，清晰把握更换底层版本的合理时间窗口。针对许多开发者经常问到的“新起项目应该选哪个 Python 版本”这一现实问题，码农高天分享了自己的实用选型策略：

- **选择正式版中“第二新”的版本**：码农高天个人的习惯做法是采用正式发布版本中次新的版本。例如当前最新发布的版本是 3.13，那么新立项的应用一般优先选用 3.12。这种策略可以在兼顾前沿特性的同时，避开刚发布版本可能残留的边缘瑕疵，在稳定性和新功能之间取得极佳的平衡。 - **依据小版本修订成熟度介入最新版**：当最新的大版本迭代到 `.2` 或 `.3` 的小版本时（例如 3.13.3），系统的稳定性已经得到了充分验证，直接选用最新版本也是完全没有问题的。 - **依据关键核心特性驱动版本升级**：如果新版本中包含对当前业务瓶颈至关重要的新功能，应当积极向该版本靠拢。以 Python 3.11 为例，该版本在运行性能上带来了颠覆性的优化，正如码农高天给咨询者的建议：“起码换到 3.11，因为 3.11 的性能提升还是非常显著的，几乎是白给的性能。”开发者应保持对新版本核心特性的关注，结合项目实际需求权衡升级。

## Notable quotes > [01:48](https://www.youtube.com/watch?v=wgfZpqJqX9Y&t=108s) Python 的团队要同时维护 6 到 7 个版本，对于一个几乎完全是为爱发电的团队来说，其实还是有不小压力的。 — 码农高天

## Mentioned Python, 码农高天, Release Manager, PEP, REPL

## Video description 这期视频我们来详细介绍一下python每个版本的生命周期，让大家对版本发布这个事情有一个更清晰的概念。

[Source](https://www.youtube.com/watch?v=wgfZpqJqX9Y)

中文简报

Python核心团队承压维护七大分支 建议新项目首选次新版本 针对 Python 五年生命周期内新旧重合的维护现状，新立项应用应优先采用次新版本或等待最新版本更新至两到三个修订号，以在规避早期边缘瑕疵的同时兼顾前沿特性与性能收益。 视频全面梳理了 Python 版本从启动开发到彻底退役的完整周期。每个版本历经约 17 个月的开发与测试，在经历每月的 Alpha 迭代、次年 5 月特性锁定的 Beta Freeze 以及高稳定要求的 RC 阶段后，于 10 月正式推出；发布后则进入为期 5 年的官方支持，涵盖 2 年的 Bug 修复期与 3 年的安全维护期直至最终 EOL。针对核心团队需同时维护 6 至 7 个重叠分支的现实与开发者的版本焦虑，作者给出了新项目选型的实用策略：优先考虑已兼顾稳定性的“次新”版本，或在最新版本迭代至 .2/.3 补丁包后接入，亦可根据 3.11 等关键性能跃升特性果断升级。 Python 每个新版本的完整开发与维护周期约为六年半，其中历时约 17 个月从立项走完 Alpha、Beta Freeze 和 RC 测试并发布 .0 正式版，随后享受为期 5 年的官方支持。 (0:00) 自 Python 3.13 起，官方正式将 Bug Fix 维护阶段从原本的一年半延长至整整两年，随后接续 3 年的 Security Fix 阶段，直至 5 年寿命到期（EOL）。 (1:48) 由于版本周期重叠，以志愿奉献为主的 Python 核心开发团队在任何时间点都需要并行维护 6 至 7 个版本分支，在生态升级成本与版本碎片化之间保持权衡。 (1:48) 针对新项目选型，码农高天建议优先考虑正式版中“第二新”的版本，或等待最新版迭代至 .2 或 .3 修订版后再接入，在系统稳定性与前沿特性间取得平衡。 (5:00)

Reading summary

码农高天梳理了 Python 高度规范化的版本生命周期机制：每个版本历经约 17 个月的开发与测试，并在发布后享有为期 5 年的官方维护；这一节奏不仅维系着开源生态的稳定演进，也为开发者的版本选型提供了清晰路径。 从开发立项到正式发布的十七个月周期 (0:00) Python 每个版本均由专门指定的 Release Manager 统筹并以 PEP 固化发布路线图，通常单人会连续负责两个版本。新版本于每年 5 月在主分支（main branch）启动开发，10 月推出首个供尝鲜测试的 Alpha 版本，随后基本以每月一版的速度持续迭代，直至次年 5 月建立专属分支并触发“Beta Freeze”。 Beta Freeze 标志着新特性开发彻底截止，分支仅允许合入缺陷修复，大型第三方开源项目通常在此阶段开展兼容性测试。随后的 RC（Release Candidate）候选阶段对反向移植（backport）的代码审查极其严苛，首要规避副作用以保障稳定性，最终在立项约 17 个月后的 10 月份推出 .0 正式版。 五年维护期划分与核心团队的维护压力 (1:48) 正式版发布后将进入 5 年官方支持周期：前 2 年为 Bug Fix 阶段（自 Python 3.13 起由此前的约一年半调整延长至整整两年），约每两个月发布一次微版本；后 3 年转入 Security Fix 阶段，仅针对高危漏洞提供安全补丁；满 5 年则正式进入 EOL（End of Life），停止所有官方支持。 由于各版本周期重叠，核心团队通常需要同时维护 6 到 7 个版本分支。码农高天指出，这对于主要“为爱发电”的团队带来了相当大的维护压力；语言团队始终在权衡两难：支持周期过短会迫使用户过于频繁地升级生产环境，而周期过长则会导致大量用户驻留陈旧版本，阻碍新特性的普及并加剧历史包袱。 兼顾稳定性与性能收益的选型逻辑 (5:00) 针对新项目启动时的版本抉择，码农高天建议优先选用正式版本中“第二新”的版本（例如 3.13 推出后优先选 3.12），此策略可在兼顾前沿特性的同时规避刚上线时残留的边缘瑕疵。若希望直接使用最新版本，可等待其小版本迭代至 .2 或 .3、稳定性经充分验证后再行介入。 此外，升级决策也可由核心关键特性驱动。如果新版本包含对业务瓶颈至关重要的改进（如 Python 3.11 带来的显著运行性能提升），开发者应积极评估并主动向新版本靠拢。 掌握 Python 的生命周期规律，能帮助开发团队更合理地规划系统底层升级窗口，在避免陈旧版本技术债务的同时，稳妥获取语言演进带来的性能与功能红利。

Source quotes

[1:48] 码农高天: Python 的团队要同时维护 6 到 7 个版本，对于一个几乎完全是为爱发电的团队来说，其实还是有不小压力的。

Original transcript

[0:00] 前两天Python3.14的Beta版本刚刚发布,这也意味着3.15的开发正式开始这期视频我想和大家介绍一下Python作为一个有几百万人使用的大型项目是怎么做版本维护的也就是每个Python版本的生命周期是什么样的首先每个PATM版本都会有一个Release Manager负责所有跟Release相关的事情每个Release Manager一般是负责两个版本Release Manager会对每个版本提一个PAP标明这个版本的预计发布时间节点这几年的版本生命周期基本是固定的每年5月份前一个版本会建立自己的branch新版本的开发就正式开始了比如前两天开了这个3.14的branch 就意味着现在的main branch 3.15了5月份开始开发,到10月份发布第一个Alpha版本这个版本是官方发布的第一个可安装版本但是Alpha版本的feature是随时可能变动的更多的是给想这个常先的人做适用 然后做反馈从第1个Alpha版本开始到第2年的5月份,中间每个月会再发布一个Alpha版本这期间一直是在main branch上直接开发到5月份的时候会建立一个属于这个版本的branch这个节点我们叫beta freezeBeta Freeze 意味着所有这个版本的新功能开发都停止了同时发布第一个Beta版本Beta版本的稳定性就要高于Alpha一些使用比较广的项目就要开始测试自己的项目能不能跑在这个版本上BetaFreeze之前的几周一般是整个Python社区最活跃的一段事情我前一阵也是加班加点的在做feature和reviewCoreDive也是有拖延症的有不少新功能都是卡着Betafreeze的节点闷进去的 比如去年的新的repleBeta Freeze之后呢,这个版本的Branch就只接受Bug Fix,新功能的开罚都是在Main Branch,也就是下一个版本。嗯Beta阶段会持续三个月左右然后进入一个叫RC的阶段它是release candidate的意思RC其实和β本质上是类似的只不过这个阶段对稳定性的要求会更高对这个backport的bug fix会更挑剔会去思考这个fix有没有可能有一些side effect啊去把其他的东西搞坏了这个时候就是稳定性压倒一切准备发布第一个正式版本RCE会发布至少两个版本,根据当时的反馈决定要不要继续发有的时候会发三个RC版本一般情况下10元左右在经过了两三个RCE版本之后就会发布第一个正式版也就是第二零版本从第一个版本开始开发到正式发布大概是17个月的开发时间在这之后呢 这个版本会经历两年的bug fix 阶段 这两年里会继续修复这个版本的bug大概每两个月出一个新版本两年之后会再有三年的Security Fix阶段这个阶段普通的bug就不凶了只有和安全相关的问题会答不定这两年加三年一共是五年的时间 就是这个版本的官方支持时间过了5年这个版本就EOL了如果你把现在所有的还在支持的python版本从正式版发布开始的生命周期叠到一起就会得到一个这样的土大家可以看到3.12之前的版本 bugfix时间会少一些,是一年半左右这个是3.13的时候改到两年的从图里大家应该能看出来Python的团队呢要同时维护6到7个版本对于一个几乎完全是为爱发电的团队来说其实还是有不小压力的当然对于任何一个语言团队来说都需要面临一个平衡的问题怎么在让用户应用尽量保持稳定的情况下推出更好的feature让大家去使用版本维护的时间太短了,所有用户都要太过频繁的进行更新维护时间太长了太多用户停留在老版本新的功能很难推广历史的一流问题很难处理我们做这个视频呢 当然不是让大家给python出谋划策 更多的是让大家了解一下版本生命周期 这样自己做应用来 [5:00] 概念大概多久需要换一下版本顺便让大家了解一下大型项目的版本维护大概是有什么情况啊那也会经常有朋友问我说如果我现在开始要做一个新的应用应该有什么版本我个人的习惯是用正式版里第二新的版本可以在稳定性和新功能里找到一个比较好的平衡比如现在最新的版本是3.13对吧那我开新的应用一般就用3.12当然了 因为现在3.13已经更新到了3.13.3了 我觉得用最新版本也是完全没问题的我感觉是到了.2.3的时候这个版本就相对比较稳定嗯另外就是关注一下每个版本对你来说比较重要的新功能如果有某个新功能对你的应用很有帮助,那肯定是要尽量往那个版本靠。比如前一阵,有人问我说,现在有一个程序,要更新Python版本了,应该用哪个版本?我就会说,起码换到3.11。因为3.11的性能提升还是非常显著的几乎是白给的性能嗯不过这些细节可能就需要你更关注新版本的信息了好了那这一期视频道理啊喜欢上简单关注不要理解三流优优独播剧场——YoYo Television Series Exclusive