我正在寻找一些希望引入 Python 3.6 的软件，以便在以 3.5 为标准的环境中使用。阅读 Python 的文档，我找不到任何关于是否：
this page about porting to 3.7 的存在让我强烈地想不，但我看不到有关版本号含义的官方文档（如果有的话，ala Linux 内核版本控制）
在更一般的意义上 - 在 3.X 发布流中是否有围绕兼容性标准的 PEP？
【问题讨论】：
标签： python python-3.x backwards-compatibility forward-compatibility
简短的回答是“不”，长的回答是“他们争取接近它的东西”。
通常，微版本与语义版本控制规则相匹配；他们不应该破坏任何东西或添加功能，只是修复错误。情况并非总是如此（例如3.5.1 broke vars() on a namedtuple, because it caused a bug that was worse than the break when it came up），但代码（尤其是 Python 级别的东西，而不是 C 扩展）很少会突破微边界。
次要版本主要是“添加功能”，但它们也会进行向后不兼容的更改事先警告。例如，async and await became keywords in Python 3.7，这意味着将它们用作变量名的代码损坏了，但启用了警告，you would have seen a DeprecationWarning in 3.6。许多语法更改最初是作为来自特殊 __future__ 模块的可选导入引入的，并记录了成为默认行为的时间线。
在次要版本中所做的更改都不是广泛的更改；我怀疑任何个别的弃用或语法更改甚至影响了 1% 的现有源代码，但它确实发生了。如果您有一百个第三方依赖项，并且您正在跳过一两个次要版本，那么其中一个很可能会被更改破坏（例如：pika 之前的 0.12使用 async 作为变量名，并在 Python 3.7 上中断；他们发布了修复错误的新版本，但当然，从0.11 和更低版本到0.12 和更高版本更改了他们自己的 API，可能会破坏你的代码）。
主要版本大致如您所料；向后不兼容的更改是预期/允许的（尽管它们通常不会轻率地进行；更改越大，好处越大）。
重点是，它接近语义版本控制，但为了不每隔几年发布一次主要版本，同时也不让语言由于严格的兼容性限制而停滞不前，允许次要版本破坏少量现有代码，因为只要有警告（通常是使用已弃用行为的代码发出的实际警告、What's New 文档中的注释，有时还支持__future__ 以简化迁移路径）。
所有这些都在他们的Development Cycle documentation 中正式记录（细节略少）：
为了澄清术语，Python 使用
major.minor.micro命名法来表示生产就绪版本。所以对于 Python 3.1.2 final，即 major version 为 3，minor version 为 1，micro version 为 2。
- 新的主要版本是例外；它们仅在认为有必要进行强烈不兼容的更改并且提前很长时间计划时才会出现；
- 新的次要版本是功能版本；它们每年都会从当前正在开发的分支中发布；
- 新的微版本是错误修复版本；他们大约每 2 个月发布一次；它们是在维护分支中准备好的。
【讨论】：
Here's the document on updating to 3.6.
例如，如果您在 3.5 中的代码中有 open(apath, 'U+')，则在 3.6 中它会失败。因此，很明显，Python 3.6 并不完全向后兼容 3.5 中的所有用法。
实际上，您需要进行测试，尽管我很乐意告诉几乎每个领域的普通 stackoverflow 读者，他们应该对进行此升级感到满意。
至于语义版本控制，具体来说，Python 不遵循它，但它并不完全不知道主要、次要和错误修复版本的含义。可以在 here 找到其开发人员的 Python 指南。
为了澄清术语，Python 使用了 major.minor.micro 命名法 用于生产就绪版本。所以对于 Python 3.1.2 final，这是一个 主要版本 3，次要版本 1，以及微型版本 2。
- 新的主要版本是例外；它们仅在认为有必要进行强烈不兼容的更改并且计划很长时间时才会出现 提前；
- 新的次要版本是功能版本；它们每年都会从当前正在开发的分支中发布；
- 新的微版本是错误修复版本；他们大约每 2 个月发布一次；它们是在维护分支中准备好的。
另请阅读PEP440，这是针对模块的，与发布新版本的 python 本身无关，但仍然与生态系统的理念相关。
【讨论】：