向後相容性政策¶
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 之後，應後續追蹤初步概念驗證的 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+ |
