尽管人们普遍认为，Python 并未使用行业标准语义版本控制，这导致了对向后兼容性和生命周期终止预期方面的不满。
Python 核心维护者正在游说改变此编程语言的版本编号方式。
目前 ，Hugo van Kemenade将作为即将发布的 Python 3.14 和 3.15 版本的发布经理，他撰写了 PEP 2026 提案“ Python 的版本控制日历”，用于指导如何对所有未来版本进行编号。
简而言之，该提案建议将 Python 版本编号为 3.YY.micro，详细说明如下：
-
3 是主版本号 - 它始终为 3.YY
-
是次版本号 - 它是短年份数字：{year} - 如2000。
-
micro是微版本号 - 它随着每个错误修复或安全版本发布而增加。
他表示，永远都不会有 Python 4，这意味着 “Python 3”将成为未来的品牌。
因此说来，Python 3.15 实际上是 3.26，其中“26”代表发布年份（如“2026”）。
Python 生命周期
van Kemenade 这样表示道：
“此举旨在使语言技术支持与生命周期更加清晰，让人们能够轻松了解某个版本首次发布的时间，并更容易确定该版本何时会达到使用寿命结束 (EOL)”。
可以确定的是，每个 Python 版本都将支持五年。
自 2019 年以来，Python 每年的主版本更新都会按照PEP 603设定的发布时间表进行。他表示，这种编号方式可以更好地反映开发的节奏。
许多人认为 Python 遵循了语义版本控制的行业标准。
SemVer 标准规定版本号的格式为 MAJOR.MINOR.PATCH，其中 MAJOR 表示重大更新（可能会破坏 API 向后兼容性），MINOR 表示没有重大更改的版本，而 PATCH 仅用于补丁。
这种认为 Python 会进行语义版本控制的假设导致了一些问题，因为每年发布的许多 Python 3 版本实际上都破坏了向后兼容性。尽管用户认为并非如此，因为所有新版本都在 3.XX 树中。但主要版本在第一个点后递增，即当前版本是 3.12，而下一个主要版本（今年晚些时候）将会是 3.13。
这些版本中的任何一个都可能带来重大变化，违反 SemVer 约定。Python 实际上比语义版本标准早了大约 15 年。
Van Kemenade 撰写了他的提案，并在上个月于匹兹堡举行的Pycon 2024 会议上提出了该提案。
van Kemenade 建议 Python 不要采用 SemVer，而是采用越来越常见的日历版本控制(CalVer)，其在编号中包含了公历年份的一些元素。
摘自 Hugo van Kemenade (Python 基金会) 的演讲
例如，Canonical 使用日历友好的 YY.0M.micro，其中年份用 YY 表示，月份用 oM 表示，修补版本用 micro 表示。因此，当前的 Ubuntu 版本是24.02。
展望未来，Python 版本将做如下发布：
-
3.15.0 将于 2026 年发布（3.26）
-
3.16.0 将于 2027 年发布（3.27）
-
3.17.0 将于 2028 年发布（3.28）
-
3.18.0 将于 2029 年发布（3.29）
-
3.19.0 将于 2030 年发布（3.30）
在 Slashdot 上的观察人士持怀疑态度的指出，这种两位数的版本计算方法在世纪之交会出现一些问题，两位数的年份标识会产生歧义，使得构建系统难以自动更新到编程语言的最新版本等等其它问题。
在 2100 年，Python v3.00 会跟随 Python v3.99 吗？
一位开发者打趣道：“难道千年虫问题没有给我们带来什么教训吗？！”
