後方互換性ポリシー

Pytest は、数十年にわたって作られてきた積極的に進化しているプロジェクトです。 私たちは、テストに関するさまざまな詳細を表現するための新しく、より良い構造について学び続けています。

これらの変更を実装する際には、スムーズな移行を確保し、ユーザーやコミュニティ/プラグイン作成者に不必要な混乱を与えないように努めています。

現在、pytest は複数の種類の後方互換性の移行を考慮しています。

1. 些細なもの: 新しいメカニズムに簡単に変換され、問題のある変更を引き起こさない API。

   私たちは、ユーザーがドキュメントを通じて新しい、またはより良いメカニズムに切り替えることを奨励しながら、それらを無期限にサポートしようとしています。

2. 移行期間: 古い API と新しい API が競合せず、両方を長期間サポートしながら警告を使用してユーザーの移行を支援できます。

   非推奨の機能の削除はメジャーリリースでのみ開始し (例: 3.0 で非推奨にしたものは 4.0 で削除を開始)、少なくとも 2 回のマイナーリリースの間は保持します (例: 3.9 で非推奨にしたものは次のリリースが 4.0 であっても 5.0 で削除を開始し、4.0 では削除しません)。

   メジャーバージョン X で削除予定の非推奨機能は、警告クラス PytestRemovedInXWarning (PytestDeprecationWarning のサブクラス) を使用します。

   非推奨期間が終了したとき (例: 4.0 がリリースされたとき)、非推奨機能をすぐに削除するのではなく、標準の警告フィルタを使用して PytestRemovedInXWarning (例: PytestRemovedIn4Warning) をデフォルトで エラー に変えます。 このアプローチにより、削除が差し迫っていることが明示され、非推奨機能をエラーではなく警告に変える時間が与えられます。 次のマイナーリリース (例: 4.1) で、その機能は実質的に削除されます。

3. 通常の移行が不合理に持続不可能であり、重要な開発や機能を数年遅らせる場合にのみ、真の破損を考慮する必要があります。 さらに、実際のユーザー数が非常に少ない API (例えば、一部のプラグインにのみ影響するもの) に限定され、事前にコミュニティと調整できる必要があります。

   このような今後の変更の例:

   • pytest_runtest_protocol/nextitem の削除 - #895

   • FunctionDefinition を含むようにノードツリーの再配置

   • SetupState の再配置 #895

   真の破損は、まず次の内容を含む issue で発表する必要があります:

   • 変更の詳細な説明

   • 根拠

   • ユーザーおよびプラグイン作成者への予想される影響 (#895 の例)

   issue に対して強い反対 (-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 で削除を開始)、少なくとも 2 回のマイナーリリースの間は保持します (例: 3.9 で非推奨にしたものは次のリリースが 4.0 であっても 5.0 で削除を開始し、4.0 では削除しません)。

非推奨期間が終了したとき (例: 4.0 がリリースされたとき)、非推奨機能をすぐに削除するのではなく、標準の警告フィルタを使用してそれらをデフォルトで エラー に変えます。 このアプローチにより、削除が差し迫っていることが明示され、非推奨機能をエラーではなく警告に変える時間が与えられます。 次のマイナーリリース (例: 4.1) で、その機能は実質的に削除されます。

非推奨ロードマップ

現在非推奨となっている機能および以前のリリースで削除された機能は、Deprecations and Removals にあります。

マイルストーンおよび GitHub 上の deprecation および removal ラベルを使用して、将来の非推奨および機能の削除を追跡します。

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+

Python バージョンのステータス。