リリースプロセス¶
リリース頻度¶
pipプロジェクトは、main
ブランチにあるものを3ヶ月ごとにリリースするという頻度でリリースしています。これにより、ユーザーはリリース時期を予測できるようになり、長期間にわたって改善や修正を保留するのを防ぎつつ、バージョン番号によってユーザーベースが大きく分断されるのを防ぎます。
リリース月は1月、4月、7月、10月です。その月内のリリース日は、そのリリースのリリースマネージャーが決定します。変更がない場合は、そのリリース月はスキップされ、次のリリースは3ヶ月後になります。
pipのバージョン番号はYY.N
です。YY
はリリース年、N
は年の四半期(0-3)を表します。
リリースマネージャーは、独自の裁量で、リリースにプレリリース期間を設けるかどうか、必要に応じてその期間を翌月に延長するかどうかを決定できます。
main
ブランチから直接リリースが行われるため、main
ブランチは常にリリース可能な状態であることが不可欠です。新機能を部分的に実装するPRのマージは許容されますが、部分的に実装されたバージョンがその状態で使用可能である場合(たとえば、機能が制限されているか、デフォルトで無効になっている場合)に限ります。マージされたPRがリリース前に追加の作業が必要であることが判明した場合、リリースマネージャーは常にリリース前に部分的な変更を取り消すオプションがあります。その後、PRを修正して次のリリースのために再提出できます。
ベンダーの更新は、他の更新と同様にmain
ブランチから取得されます。理想的には、ベンダーの更新は、他の変更と同様にリリース間でマージする必要があります。ベンダーパッケージに未解決の更新がある場合、リリースマネージャーは独自の裁量でリリース前にベンダーの更新を行うことができます。ただし、これは必須ではなく、特にpipのバグを修正するベンダーパッケージの更新は、次のリリースに含まれるように積極的にマージする必要があります。
非推奨ポリシー¶
pipのドキュメントに記載されているユーザーに見える動作を削除または大幅に変更するpipへの変更は、変更が発生する前に最低6ヶ月間非推奨とされます。
特定の変更は迅速化され、非推奨期間を3ヶ月にすることができます。これには、pipチームの少なくとも2人のメンバーがこのことに賛成し、pipメンテナーが反対しないことが必要です。
非推奨は、機能が使用されたときにpipによって警告が発せられる形式で行われます。状況によっては、より長い非推奨期間、または通常はこのポリシーの対象とならない動作変更に関する非推奨警告も可能ですが、これはpipメンテナーの裁量に委ねられます。
ドキュメントは、合意された動作としてカウントされるものの唯一の参照であることに注意してください。ドキュメントに明示的に記載されていないものは、警告なし、またはpipリリースでの非推奨期間なしで変更される可能性があります。ただし、ドキュメントが常に完全ではないことを認識しています。上記の非推奨プロセスでその動作を網羅することを目的として既存の動作を文書化するPRは常に受け入れられ、そのメリットに基づいて検討されます。
注記
pipには、pipメンテナーが非推奨を容易にするためのヘルパー関数があります。pip._internal.utils.deprecation.deprecated
のソースコードにサポートドキュメントがあります。この関数は、pipのパブリックAPIの一部ではありません。
サポートされているバージョン¶
pipの最新バージョンのみがサポートされています。以前のバージョンはサポートされていないと見なされます。ユーザーは、サポートされるようにpipのバージョンを定期的に更新することをお勧めします。
Python 2サポート¶
pip 20.3は、Python 2をサポートした最後のpipバージョンでした。Python 2.7でのみ発生するpipのバグレポートは、pipのメンテナーによって「修正しない」問題として閉じられる可能性があります。
Pythonサポートポリシー¶
pipは寿命が尽きていないCPythonバージョンをサポートしています。古いバージョンのCPythonは、pipメンテナーの裁量でサポートされる場合があります(PyPIのダウンロード統計、ベンダー依存関係でサポートされているPythonバージョン、メンテナンスの負担などの基準に基づきます)。
pipメンテナーは、他のPython実装をサポートするためのプルリクエストを受け入れますが、pip CIではそれらとの互換性テストは行いません。
機能フラグ¶
--use-deprecated
¶
例:--use-deprecated=legacy-resolver
非推奨となる機能に使用します。非推奨機能は、非推奨ポリシーに従って、少なくとも6ヶ月間は、このフラグの背後で利用可能である必要があります。
このフラグの背後に移動された機能には、機能が削除される予定時期を示す警告を常に含める必要があります。
機能が削除されると、フラグを使用するユーザーにはエラーが表示されます。
--use-feature
¶
例:--use-feature=2020-resolver
ユーザーがpipのデフォルトの動作になる前にテストできる新しい機能(アルファ版またはベータ版リリースなど)に使用します。
機能がデフォルトの動作になると、このフラグはそのまま残すことができますが、ユーザーに不要になったことを伝える警告を表示する必要があります。
リリースプロセス¶
新しいリリースの作成¶
最新の
nox
がインストールされていることを確認します。main
から新しいrelease/YY.N
ブランチを作成し、それに切り替えます。nox -s prepare-release -- YY.N
を使用してリリースの準備をします。これにより、関連ファイルが更新され、正しいコミットにタグが付けられます。release/YY.N
ブランチをプルリクエストとして送信し、CIがパスすることを確認します。main
に変化をマージし、ローカルにプルします。nox -s build-release -- YY.N
を使用してリリースアーティファクトをビルドします。これにより、タグがチェックアウトされ、アップロードする配布ファイルが生成され、mainブランチが再度チェックアウトされます。nox -s upload-release -- YY.N
を使用してリリースをPyPIにアップロードします。prepare-release
によって作成されたタグをプッシュします。get-pipリポジトリで
get-pip.py
スクリプトを再生成し(そこに記載されているとおり)、結果をコミットします。CPythonにプルリクエストを送信し、新しいバージョンのpipを
Lib/ensurepip/_bundled
に追加し、既存のバージョンを削除し、Lib/ensurepip/__init__.py
にリストされているバージョンを調整します。
注記
リリースで古いPythonバージョンM.m
のサポートが削除された場合、新しいM.m/get-pip.py
を公開する必要があります。get-pipリポジトリのtasks/generate.py
からall
タスクを更新し、psf-saltリポジトリにプルリクエストを作成して新しいget-pip.py
(とそのディレクトリ)をsalt/pypa/bootstrap/init.sls
に追加します。
注記
pip内部の変更によりget-pip.py
スクリプトの更新が必要で、最後に公開されたM.m/get-pip.py
がまだデフォルトテンプレートを使用している場合、更新する前にまずtemplates/default.py
をtemplates/pre-YY.N.py
として複製し、tasks/generate.py
でM.m/get-pip.py
がtemplates/pre-YY.N.py
を使用する必要があることを指定してください。
バグ修正リリースの作成¶
場合によっては、YY.N.Z+1
形式のバグ修正リリースを行う必要があります。これを作成するには、変更をすでにmain
ブランチにマージしておく必要があります。
このプロセスは、バグ修正リリースに含めたくない変更がmain
ブランチにある場合にのみ必要です。main
ブランチにあるすべての変更を含むバグ修正リリースの場合、バージョン番号を変更するだけで、新しいリリースを作成する上記のプロセスを使用できます。
YY.N
タグから新しいrelease/YY.N.Z+1
ブランチを作成するには、git checkout -b release/YY.N.Z+1 YY.N
コマンドを使用します。main
ブランチから修正されたコミットをチェリーピックし、競合を解決します。nox -s prepare-release -- YY.N.Z+1
を実行します。メインブランチをリリースブランチにマージし、リリースに含まれているニュースファイルを削除します(そうでないと、
YY.N+1
の変更ログにも表示されます)。release/YY.N.Z+1
ブランチをgithubにプッシュし、main
ブランチに対してPRを提出し、テストの実行を待ちます。テストが実行されたら、
release/YY.N.Z+1
ブランチをmain
にマージし、ステップ5から上記のリリースプレセスに従います。