向后兼容性策略¶
Pytest 是一个活跃发展的项目，已经酝酿了数十年。我们不断学习新的、更好的结构来表达测试的不同细节。
在实施这些修改时，我们力求确保平稳过渡，不愿给我们的用户和社区/插件作者带来不必要的麻烦。
截至目前，pytest 考虑了多种类型的向后兼容性过渡：
微不足道（trivial）：API 可以轻松地转换为新机制，不会导致问题性更改。
我们力求无限期支持这些 API，同时通过文档鼓励用户切换到更新或更好的机制。
过渡性（transitional）：新旧 API 不冲突，我们可以通过使用警告来帮助用户过渡，同时在较长时间内支持两者。
我们只会在主要版本中开始移除已弃用的功能（例如，如果我们在 3.0 中弃用某些功能，我们将在 4.0 中开始移除），并至少保留两个次要版本（例如，如果我们在 3.9 中弃用某些功能，而 4.0 是下一个版本，我们将在 5.0 中开始移除，而不是在 4.0 中）。
计划在主要版本 X 中移除的已弃用功能将使用警告类
PytestRemovedInXWarning（PytestDeprecationWarning的子类）。当弃用期满（例如，4.0 发布）时，我们不会立即移除已弃用的功能，但会使用标准警告过滤器将
PytestRemovedInXWarning（例如，PytestRemovedIn4Warning）默认转换为错误。这种方法明确表示移除迫在眉睫，同时仍为您提供时间将已弃用的功能转换为警告而不是错误，以便您可以根据自己的时间处理。在下一个次要版本（例如，4.1）中，该功能将实际移除。只有当正常过渡不合理地不可持续并可能使重要开发或功能推迟数年时，才应考虑真正的破坏性变更。此外，它们应仅限于实际用户数量非常少的 API（例如，仅影响某些插件），并且可以提前与社区协调。
此类即将到来的更改示例
真正的破坏性变更必须首先在包含以下内容的 issue 中宣布：
更改的详细描述
基本原理
对用户和插件作者的预期影响（示例见 #895）
如果没有明确的-1反对意见，则应跟进一个初步的概念验证拉取请求。
这个 POC 既作为评估影响的协调点，也可能作为最终提出过渡解决方案的灵感。
在合理的时间后，PR 可以合并以作为新主要版本的基础。
为了使 PR 从 POC 成熟到被接受，它必须包含： * 设置弃用错误/警告，帮助用户修复和移植其代码。如果可能在当前系列中，在真正的破坏性变更之前引入弃用期，则应在单独的 PR 中引入，并作为当前发布流的一部分。 * 在
doc/en/deprecations.rst中详细描述基本原理和如何移植代码的示例。
历史¶
主要关注平稳过渡 - 立场（6.0 之前）¶
保持向后兼容性在 pytest 项目中具有非常高的优先级。尽管多年来我们已经弃用了一些功能，但其中大部分仍受支持。pytest 中的所有弃用都是因为出现了更简单或更有效的方法来完成相同的任务，使得旧的做事方式变得不必要。
随着 pytest 3.0 的发布，我们引入了一个清晰的沟通方案，说明何时我们将实际移除旧的故障功能，并礼貌地要求您使用新的热门功能，同时给您足够的时间调整您的测试，或在有充分理由保留已弃用功能的情况下提出疑虑。
为了传达更改，我们使用自定义警告层次结构发出弃用警告（参见内部 pytest 警告）。这些警告可以使用标准方式抑制：-W 命令行标志或 filterwarnings ini 选项（参见如何捕获警告），但我们建议少量临时使用这些方式，并在可能的情况下听取警告。
我们只会在主要版本中开始移除已弃用的功能（例如，如果我们在 3.0 中弃用某些功能，我们将在 4.0 中开始移除），并至少保留两个次要版本（例如，如果我们在 3.9 中弃用某些功能，而 4.0 是下一个版本，我们将在 5.0 中开始移除，而不是在 4.0 中）。
当弃用期满（例如，4.0 发布）时，我们不会立即移除已弃用的功能，但会使用标准警告过滤器将它们默认转换为错误。这种方法明确表示移除迫在眉睫，同时仍为您提供时间将已弃用的功能转换为警告而不是错误，以便您可以根据自己的时间处理。在下一个次要版本（例如，4.1）中，该功能将实际移除。
弃用路线图¶
当前已弃用并在以前版本中移除的功能可以在弃用和移除中找到。
Python 版本支持¶
发布的 pytest 版本支持发布时所有积极维护的 Python 版本
pytest 版本 |
最低 Python 版本 |
|---|---|
8.4+ |
3.9+ |
8.0+ |
3.8+ |
7.1+ |
3.7+ |
6.2 - 7.0 |
3.6+ |
5.0 - 6.1 |
3.5+ |
3.3 - 4.6 |
2.7, 3.4+ |