python 3在语义上是否版本化并且转发兼容 [英] Is python 3 semantically versioned and forwards compatible

问题描述

我正在寻找一些想要引入Python 3.6的软件，以便在以3.5为标准的环境中使用.在阅读Python文档时，我找不到有关以下内容的任何信息:

I'm looking at some software that is wanting to bring in Python 3.6 for use in an environment where 3.5 is the standard. Reading up on Python's documentation I can't find anything about whether:

• 3.5代表语义版本号
• 3.6将表示向前兼容的升级(即:保证为3.5运行时编写的代码可以在3.6运行时中运行)

此页面关于移植到3.7的事实存在使我强烈考虑 no ，但是我看不到有关版本号含义的官方文档(如果有的话，ala Linux内核版本控制)

The fact that this page about porting to 3.7 exists makes me think strongly no but I can't see official docs on what the version numbers mean (if anything, ala Linux kernel versioning)

从更一般的意义上讲，3.X版本流中是否存在有关兼容性标准的PEP?

In the more general sense - is there a PEP around compatibility standards within the 3.X release stream?

推荐答案

简短的回答是否"，长回答是他们努力争取接近它的东西".

The short answer is "No", the long answer is "They strive for something close to it".

通常，微型版本与语义版本控制规则匹配；他们不是应该破坏任何东西或添加功能，而只是修复错误.情况并非总是如此(例如 3.5.1在namedtuple上破坏了vars()，因为它导致了更严重的错误) )，但是对于代码(尤其是Python级别的东西，而不是C扩展名)来说，跨越微观边界是非常罕见的.

As a rule, micro versions match semantic versioning rules; they're not supposed to break anything or add features, just fix bugs. This isn't always the case (e.g. 3.5.1 broke vars() on a namedtuple, because it caused a bug that was worse than the break when it came up), but it's very rare for code (especially Python level stuff, as opposed to C extensions) to break across a micro boundary.

次要版本主要是添加功能"，但是它们也会在向后不兼容的更改中发出事先警告.例如， async和await成为关键字在Python 3.7 中，这意味着将使用它们作为变量名的代码损坏了，但是启用了警告，您会在3.6中看到DeprecationWarning .最初，从特殊的__future__模块中引入了许多语法更改作为可选导入，并记录了成为默认行为的时间表.

Minor versions mostly "add features", but they will also make backwards incompatible changes with prior warning. For example, async and await became keywords in Python 3.7, which meant code using them as variable names broke, but with warnings enabled, you would have seen a DeprecationWarning in 3.6. Many syntax changes are initially introduced as optional imports from the special __future__ module, with documented timelines for becoming the default behavior.

次要版本中所做的任何更改都不是广泛的更改.我怀疑任何个别的弃用或语法更改是否会影响现有源代码的1％，但这确实发生了.如果您有一百个第三方依赖项，并且正在跳过一两个次要版本，那么其中一个将被更改打破的可能性非常大(例如:pika在0.12之前)使用async作为变量名，并在Python 3.7上断开；他们发布了修复该错误的新版本，但是，当然，从0.11以及更低版本更改为0.12以及更高版本都改变了自己的API，可能会破坏您的代码).

None of the changes made in minor releases are broad changes; I doubt any individual deprecation or syntax change has affected even 1% of existing source code, but it does happen. If you've got a hundred third party dependencies, and you're jumping a minor version or two, there is a non-trivial chance that one of them will be broken by the change (example: pika prior to 0.12 used async as a variable name, and broke on Python 3.7; they released new versions that fixed the bug, but of course, moving from 0.11 and lower to 0.12 and higher changed their own API in ways that might break your code).

主要版本与您期望的大致相同；向后不兼容的更改是预期的/允许的(尽管通常不会轻率地进行更改；更改越大，收益越大).

Major versions are roughly as you'd expect; backwards incompatible changes are expected/allowed (though they're generally not made frivolously; the bigger the change, the bigger the benefit).

要点是，它接近语义版本控制，但为了每隔几年不发布主要版本，同时也由于严格的兼容性约束而不会让语言停滞，因此次要版本允许破坏少量现有代码，因为只要有警告(通常以不赞成使用的行为来自代码的实际警告形式，关于新增功能"文档的注释，有时还提供__future__支持以简化迁移路径).

Point is, it's close to semantic versioning, but in the interests of not having major releases every few years, while also not letting the language stagnate due to strict compatibility constraints, minor releases are allowed to break small amounts of existing code as long as there is warning (typically in the form of actual warnings from code using deprecated behavior, notes on the What's New documentation, and sometimes __future__ support to ease the migration path).

所有内容均在其开发周期文档中正式记录(略有减少):

This is all officially documented (with slightly less detail) in their Development Cycle documentation:

为了澄清术语，Python使用major.minor.micro术语来表示可用于生产的发行版.因此对于Python 3.1.2 final，这是3的主要版本，1的次要版本和2的 micro版本.

To clarify terminology, Python uses a major.minor.micro nomenclature for production-ready releases. So for Python 3.1.2 final, that is a major version of 3, a minor version of 1, and a micro version of 2.

• 新的主要版本是例外；只有在认为强烈不兼容的更改是必需的并且需要很长时间计划时，它们才会出现；
• 新的次要版本是功能版本；他们每年都会从当前的开发中分支机构中释放出来；
• 新的 micro版本是错误修复版本；他们大约每2个月获释一次；它们是在维护部门准备的.

• new major versions are exceptional; they only come when strongly incompatible changes are deemed necessary, and are planned very long in advance;
• new minor versions are feature releases; they get released annually, from the current in-development branch;
• new micro versions are bugfix releases; they get released roughly every 2 months; they are prepared in maintenance branches.

这篇关于python 3在语义上是否版本化并且转发兼容的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！