当前方案

摘自 Python 通用常见问题解答：Python 的版本编号方案是如何运作的？

Python 版本号为“A.B.C”或“A.B”。

• A 是主版本号 - 仅在语言发生重大变化时才增加。
• B 是次版本号 - 针对不太重大的更改进行增加。
• C 是微版本号 - 针对每个错误修复版本进行增加。

Python 早于 SemVer

语义版本控制 (SemVer) 是一种流行的方案，旨在传达版本的意图 (尽管它 并不总是成功)。

给定一个版本号 MAJOR.MINOR.PATCH，在以下情况下增加相应的值：

1. 当您进行不兼容的 API 更改时，增加 MAJOR 版本。
2. 当您以向后兼容的方式添加功能时，增加 MINOR 版本。
3. 当您进行向后兼容的错误修复时，增加 PATCH 版本。

人们经常假设 Python 遵循 SemVer 并 抱怨 关于 破坏性 更改 在 功能 版本 中。但是，Python 比 SemVer 早了至少 15 年：SemVer 规范于 2009 年引入，而 Python 的定制方案则是在 1994 年添加到源代码控制 中，用于 1.0 版本。

如果 Python 采用了 SemVer，这意味着每年删除废弃功能时都会出现新的主版本升级。

然而，除了 SemVer 之外，一些项目采用了另一种基于日历的版本控制方案。

日历版本

使用 日历版本控制 (CalVer)，您会在版本号中包含日期的某些元素。 例如，Ubuntu 和 Black 使用年份和月份 - Ubuntu 24.04 于 2024 年 4 月发布；pip 和 PyCharm 仅使用年份。

以下是一些编程语言标准，它们都使用了某种形式的年份

年度发布节奏

自 2019 年以来，我们每年都会发布一个版本。

• 3.15.0 将于 2026 年发布
• 3.16.0 将于 2027 年发布
• 3.17.0 将于 2028 年发布
• 3.18.0 将于 2029 年发布
• 3.19.0 将于 2030 年发布

这有点像基于日历的，只是它被偏移了 11 年。

Python 的 CalVer

最简单的 CalVer 选项是坚持使用主版本 3，并在次版本中编码年份。

• 3.26.0 将于 2026 年发布
• 3.27.0 将于 2027 年发布
• 3.28.0 将于 2028 年发布
• 3.29.0 将于 2029 年发布
• 3.30.0 将于 2030 年发布

例如，3.26 将于 2026 年发布。它使发布的首次发布时间变得一目了然。

明确废弃功能的移除

废弃功能的警告通常会提到它们将在哪个版本中被移除。例如

DeprecationWarning: ‘ctypes.SetPointerType’ 已被弃用，并计划在 Python 3.15 中移除

然而，一旦了解了 CalVer，您就可以从警告中立即清楚地知道您需要采取行动的时间

DeprecationWarning: ‘ctypes.SetPointerType’ 已被弃用，并计划在 Python 3.26 中移除

明确支持周期

现在，确定一个版本何时到达生命周期结束有点麻烦。首先您需要查找它最初发布的时间，然后加上 5 年。

“Python 3.11 什么时候会到 EOL？”

“嗯，让我们看看… PEP 664 是 3.11 发布计划，它说 3.11 于 2022 年发布，EOL 为发布后 5 年，所以 2022 + 5 = 2027。”

但是，如果首次发布年份就在版本号中，那么会容易得多

“Python 3.26 什么时候会到 EOL？”

“26 + 5 = [20]31”

明确安装版本时间

有了版本号中的年份，更容易确定您的安装版本有多旧。例如，在当前方案中，如果您在 2035 年使用的是 Python 3.15，则不清楚它是在 2026 年首次发布的 (并且自 2031 年以来一直处于 EOL 状态)。

如果您了解 CalVer，那么如果您在 2035 年使用的是 Python 3.26，很明显它是在九年前首次发布的，现在可能是时候升级了。

这可以帮助人们切换到仍处于安全支持下的受支持版本，并有助于教授可能使用旧安装版本的新用户。

明确版本支持

CalVer 使得更容易确定要支持哪些 Python 版本。

例如，如果没有 CalVer，将您的最低兼容 Python 版本设置为 2031 年的 3.19，这会对版本采用和支持做出过于乐观的假设。

然而，有了 CalVer，将最低版本设置为 2031 年的 3.30 就更加清晰。为了更广泛的支持，您可能更喜欢将其设置为 3.26。

同样，支持所有 CPython 上游版本的库维护人员需要针对五个版本进行测试 (或者包括预发布版本在内，则为六个版本)。

例如，在 2030 年，没有 CalVer 的受支持版本将是

• 3.15, 3.16, 3.17, 3.18, 3.19

有了 CalVer，它们将是

• 3.26, 3.27, 3.28, 3.29, 3.30

维护人员可以一目了然地看到哪些版本是当前版本，需要进行测试。

非目标

与当前方案类似，仅针对错误修复和安全发布增加微版本，主版本和次版本保持不变。例如

对 PEP 602 (Python 年度发布周期) 没有任何改变。

• 对开发功能版本 (alpha 版、beta 版和发布候选版) 的 17 个月没有改变。
• 对支持时间没有改变：两年完整支持和三年安全修复。
• 对每年的 10 月发布节奏没有改变。

YY.0

例如，Python 26.0 将于 2026 年发布。

对 Python 4 版本 没有多少兴趣。 我们不想重蹈 2 到 3 的覆辙，并且 4 到现在已经有了很多期望。我们不想进行“重大的更改”。

也许 Python 4 可以为一些重大事件预留，比如移除 GIL（PEP 703），但指导委员会明确表示，免费线程的推出必须循序渐进。我们是否会永远使用 版本 3？

另一种选择是在主版本中加入年份，跳到 26.0。这意味着我们可以跳过所有 4.0 的包袱。

'this is Python {}'.format(sys.version[:5])

".%s-%s" % (get_platform(), sys.version[0:3])

if sys.version_info[1] >= 9:

if sys.version[0] == '3':

YY.MM

例如，Python 26.10 将于 2026 年 10 月发布。

基于 YY.0 版本控制，我们还可以将发布月份作为次版本，就像 Ubuntu 和 Black 一样。这将明确表明它是在哪一年发布的，以及它将在哪一年结束生命周期。

然而，YY.MM 版本控制因与 YY.0 版本控制相同的许多原因而被拒绝。

3.YYYY

例如，Python 3.2026 将于 2026 年发布。

使用四位数字更清楚地表明次版本是年份，并且避免与使用 YY.MM 的 Ubuntu 版本混淆。但是，这被拒绝，因为从两位数更改为四位数会比 3.YY 版本控制破坏更多代码。

版本

例如，Python 3.15（2026 版）将于 2026 年发布。

Rust 语言使用 “版本” 来引入重大更改。将此应用于 Python 将需要对 PEP 387（向后兼容性策略）进行重大更改，并且超出了此 PEP 的范围。

我们可以将年份标签应用于发行版，例如“Python 3.15（2026 版）”，但这是被拒绝的，因为我们必须跟踪两个数字。

采用 SemVer 并跳过 4

例如，Python 5.0 将于 2026 年发布，6.0 将于 2027 年发布，等等。

我们可以完全跳过有问题的 4.0 并采用 SemVer。由于弃用在每次功能发布中都会被移除，因此我们每年都会得到一个新的主版本提升。

这是被拒绝的，因为我们不会获得日历版本控制的好处，并且从 3.x 转移也会 破坏代码。

在 3.14 周期中更改

Python 3.14 版本必须发布，因为：π。

版本映射

版本 3.15 到 3.25（含）将被跳过。为这些版本计划的功能、弃用和移除将重新映射到新的版本号。

例如，最初计划在 3.16 中移除的弃用将改为在 3.27 中移除。

未来节奏变化

此 PEP 针对 PEP 602 中定义的年度发布节奏，没有提出任何更改，该 PEP 概述了 年度发布的许多充分理由（例如，具有可预测发布日历的较小发布，以及与外部重新分发者的同步）。然而，即使不太可能，如果我们将来决定更改节奏，CalVer 也不会阻止这样做。

不再使用 CalVer

现在采用 CalVer 并不排除将来放弃 CalVer，例如，回到原始方案、SemVer 或其他方案。一些选项 列在上面的表格中。如果想要明确表明次版本不再是年份，可以将其提升到更高的整数（例如，3.50 或 3.100），或者可以提升主版本（例如，提升到 4.0 或 5.0）。此外，可以考虑 版本纪元。