向后兼容性策略¶
Pytest 是一个活跃发展了数十年的项目。我们不断学习新的、更好的结构来表达测试的不同细节。
在实施这些修改时，我们努力确保平稳过渡，不希望给我们的用户和社区/插件作者带来不必要的麻烦。
截至目前，pytest 考虑了多种向后兼容性过渡类型
微不足道的：可以轻松转换为新机制且不会引起问题性更改的 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 意见，则应跟进一个初步的概念验证拉取请求。
这个概念验证既是一个协调点，用于评估影响，也是一个潜在的灵感来源，最终提出一个过渡性解决方案。
经过合理的时间后，该 PR 可以合并以作为新的主版本的基础。
为了使 PR 从概念验证发展到被接受，它必须包含：* 设置弃用错误/警告，帮助用户修复和移植其代码。如果可以在当前系列中引入弃用期，在真正的破坏性更改之前，则应在单独的 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）中，该功能将被有效移除。
弃用路线图¶
当前在以前版本中已弃用和移除的功能可以在 弃用和移除 中找到。
我们使用里程碑以及 GitHub 上的 deprecation（弃用） 和 removal（移除） 标签来追踪未来功能的弃用和移除。
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+ |