向后兼容性策略¶
pytest 正在积极发展，是一个历经数十年制作的项目，我们不断了解有关表达测试不同细节的新型和更好的结构。
在实现这些修改时，我们尝试确保轻松过渡，并且不想对我们的用户和社区/插件作者施加不必要的变动。
截至目前，pytest 考虑多种类型的向后兼容性过渡
平凡：以平凡方式转换为新机制的 API，并且不会导致有问题的更改。
我们尝试无限期地支持这些 API，同时通过文档鼓励用户切换到较新/更好的机制。
过渡：旧 API 和新 API 不冲突，并且我们可以在较长时间内同时支持两者，通过使用警告来帮助用户过渡。
我们只会在大版本中开始移除弃用的功能（例如，如果我们在 3.0 中弃用某个功能，我们将在 4.0 中开始移除它），并至少保留两个小版本（例如，如果我们在 3.9 中弃用某个功能，而 4.0 是下一个版本，我们将在 5.0 中开始移除它，而不是在 4.0 中）。
计划在主版本 X 中移除的弃用功能将使用警告类
PytestRemovedInXWarning（PytestDeprecationWarning的子类）。当弃用期到期（例如，发布 4.0）时，我们不会立即移除弃用的功能，但会使用标准警告过滤器将
PytestRemovedInXWarning（例如，PytestRemovedIn4Warning）默认转换为错误。此方法明确表示即将移除，并且仍然给您时间将弃用的功能转换为警告，而不是错误，以便您可以自行处理。在下一个小版本（例如，4.1）中，该功能将被有效移除。真正的破坏：只有在正常过渡不合理且会抵消多年的重要开发/功能时才应考虑。此外，它们应仅限于实际用户数量非常少的 API（例如，仅影响某些插件），并且可以与社区提前协调。
此类即将进行的更改的示例
真正的破坏必须首先在包含以下内容的问题中宣布
更改的详细说明
基本原理
对用户和插件作者的预期影响（问题 #895 中的示例）
在问题中没有明确的-1 之后，应通过最初的概念验证 Pull Request 进行跟进。
此 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.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+ |
