当前方案

来自 Python 常见问题解答：Python 版本编号方案是如何工作的？

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

• A 是主版本号——仅当语言发生真正重大的更改时才会递增。
• B 是次版本号——当发生不太“惊天动地”的更改时递增。
• C 是微版本号——每次错误修复版本发布时递增。

Python 早于 SemVer

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

给定版本号 MAJOR.MINOR.PATCH，在进行不兼容的 API 更改时增加

1. MAJOR 版本
2. 在向后兼容的方式中添加功能时增加
3. MINOR 版本

人们经常假设 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' is deprecated and slated for removal in Python 3.15

然而，一旦了解 CalVer，警告会立即清晰地显示您有多少时间来采取行动。

DeprecationWarning: 'ctypes.SetPointerType' is deprecated and slated for removal in Python 3.26

支持生命周期的清晰度

目前，要计算出版本的生命周期结束时间有点棘手。首先需要查找它最初的发布时间，然后加上 5 年。

“Python 3.11 的 EOL 是什么时候？”

“嗯，让我想想…… PEP 664 是 3.11 的发布计划，它说 3.11 是在 2022 年发布的，5 年后 EOL，所以 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 版本设置为 3.19（在 2031 年），这会根据版本采用和支持情况做出过于积极的假设。

然而，使用 CalVer，如果将最低版本设置为 3.30（在 2031 年），则更为明显。为了更广泛的支持，您可能更喜欢设置为 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 的年度发布周期）没有改变。

• 对开发功能版本的 17 个月（alpha、beta 和 release candidate）没有改变。
• 对支持期限没有改变：两年完全支持和三年安全修复。
• 对每年十月的发布节奏没有改变。

YY.0

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

人们对 Python 4 版本没有太多兴趣。我们不想重蹈 2 到 3 的覆辙，而且 4.0 版本现在承载了很高的期望。我们不希望出现“颠覆性”的更改。

也许 Python 4 可以保留给像移除 GIL（PEP 703）这样的大事，但指导委员会已明确表示自由线程的推出必须是渐进的。我们会永远坚持 Python 3 吗？我们将永远坚持 Python 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 版本混淆。

版本

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

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

我们可以为发布添加年份标签，例如“Python 3.15 (2026 Edition)”，但这被拒绝，因为我们需要跟踪*两个*数字。

采用 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 中定义的年度发布节奏，该节奏为年度发布提供了许多充分的理由（例如，更小的版本，可预测的发布日历，以及与外部再分发者的同步）。尽管可能性不大，但如果我们将来决定改变发布节奏，CalVer 并不妨碍这样做。

不再使用 CalVer

现在采用 CalVer 并不妨碍将来放弃 CalVer，例如，回到原来的方案、SemVer 或其他方案。一些选项列在上面的表格中。如果想清楚地表明次版本号不再是年份，可以将其提升到一个更高的整数（例如，3.50 或 3.100），或者提升主版本号（例如，到 4.0 或 5.0）。此外，还可以考虑使用版本 epoch。