我正在研究一些软件，这些软件希望引入Python 3.6，以便在3.5是标准的环境中使用。阅读Python的文档，我找不到任何关于是否：的信息
- 3.5代表语义版本号
- 3.6将代表向前兼容的升级(即：为3.5运行时编写的代码保证在3.6运行时中工作)
这个关于移植到3.7的页面的存在让我强烈地思考no，但我看不到关于版本号的官方文档(如果有的话，比如Linux内核版本控制)
从更普遍的意义上讲，3.X发布流中是否存在与兼容性标准相关的PEP？
简短的回答是"否"；，长答案是"；他们努力追求接近它的东西；。
通常，微版本与语义版本控制规则相匹配；他们不应该破坏任何东西或添加功能，只是修复bug。这种情况并不总是如此(例如，3.5.1在namedtuple上破坏了vars()，因为它导致了一个比出现时更糟糕的错误)，但代码(尤其是Python级别的东西，而不是C扩展)很少突破微边界。
次要版本大多是"；添加特征">，但他们也会做出向后不兼容的更改与之前的警告。例如，async和await在Python 3.7中成为关键字，这意味着使用它们作为变量名的代码会中断，但如果启用了警告，您会在3.6中看到DeprecationWarning。许多语法更改最初是作为特殊__future__模块的可选导入引入的，并记录了成为默认行为的时间表。
小版本中所做的更改都不是大范围的更改；我怀疑任何单独的弃用或语法更改都会影响到现有源代码的1%，但它确实会发生。如果你有一百个第三方依赖项，并且你正在跳过一两个次要版本，它们中的一个很可能会被更改所破坏(例如：0.12之前的pika使用async作为变量名，并在Python 3.7上被破坏；他们发布了修复错误的新版本，但当然，从0.11及更低版本移动到0.12及更高版本会以可能破坏代码的方式更改他们自己的API)。
主要版本大致如您所料；向后不兼容的更改是期望的/允许的(尽管它们通常不会轻率地做出；更改越大，好处就越大)。
重点是，它接近于语义版本控制，但为了不每隔几年就发布一次主要版本，同时也不让语言因严格的兼容性限制而停滞不前，只要存在警告，小版本就可以中断少量现有代码(通常是使用不推荐的行为、What's New文档中的注释以及有时__future__支持来简化迁移路径的代码发出的实际警告)。
这一切都在他们的开发周期文档中得到了正式记录(细节略少)：
为了澄清术语，Python使用
major.minor.micro命名法用于生产就绪版本。因此，对于Python 3.1.2的最终版本，即3的主版本、1的次版本2的1微版本2。
- 新的主要版本是例外；只有当强烈不相容的变化被认为是必要的，并且是提前很长时间计划的时候，它们才会出现
- 新的次要版本是功能发布；它们每年都会从当前的开发分支发布
- 新的微版本是错误修复版本；他们大约每两个月被释放一次；它们是在维护分支中准备的
这是关于更新到3.6的文档。
例如，如果您在3.5中的代码中有open(apath, 'U+')，那么它将在3.6中失败。因此，很明显，Python3.6并不是完全向后兼容3.5中的每一种用法。
事实上，你需要进行测试，尽管我很乐意告诉几乎每个领域的普通stackoverflow读者，他们应该觉得升级很舒服。
至于语义版本控制，特别是Python没有遵循它，但它并不完全不知道主要版本、次要版本和错误修复版本的含义。Python开发人员指南可以在这里找到。
为了澄清术语，Python使用了major.minor.micro命名法用于生产准备版本。因此，对于Python 3.1.2的最终版本3的主要版本、1的次要版本和2的次要版本。
- 新的主要版本是例外的；只有当强烈不兼容的更改被认为是必要的，并且计划得很长时，它们才会出现提前
- 新的次要版本是功能发布；它们每年都会从当前的开发分支发布
- 新的微版本是错误修复版本；他们大约每两个月被释放一次；它们是在维护分支中准备的
还请阅读PEP440，它是针对模块的，不是关于发布新版本的python本身，但仍然与生态系统的理念相关。