リリースプロセス¶
Blackのリリースプロセスは、標準化と自動化に多くの作業が投入されています。このドキュメントでは、すべてがどのように機能し、上記の自動化を使用してBlackをリリースする方法を説明します。
リリースサイクル¶
目標は、mainブランチにあるものを1～2ヶ月ごとにリリースすることです。 これにより、マージされた改善とバグ修正がユーザーに比較的迅速に提供され、一方で、あまり多くのバージョンによってユーザーベースが大きく分断されることはありません。これにより、メンテナンス担当者の作業負荷も一貫性があり、予測しやすくなります。
mainブランチにリリースを正当化するほどの新しいものがなければ、月のリリースをスキップしても問題ありません。理想的には、1月のリリースはスキップしないようにする必要があります。なぜなら、当社の安定性ポリシーに従って、新しい暦年の最初のリリースでは、安定版スタイルに変更を加える可能性があるためです。このポリシーは最初のリリースに適用されます（1月のリリースのみに適用されるのではなく）、安定版スタイルへの変更を1月に限定することで、ユーザーにとって予測可能で（そしてより良い）ものになります。
深刻な回帰またはバグがあり、即時のパッチが必要な場合を除き、1ヶ月に1回以上のリリースを行うべきではありません。 バージョン番号は安価ですが、リリースには、メンテナンス担当者が実際にリリースを行うことにコミットするだけでなく、リリース後の潜在的な問題に対処できる能力も必要です。月よりも頻繁にリリースすると、急速に収益逓減効果が生じます。
リリースの作成¶
リリースを作成するには、Blackリポジトリに対するwrite権限が必要です。
リリースプロセスの概要は、リリースPRを作成し、GitHub Releaseを公開することです。これにより、すべてのリリースアーティファクトをビルドし、公開先のさまざまなプラットフォームに公開するリリース自動化がトリガーされます。
リリースPRの作成に役立つscripts/release.pyスクリプトができました。
python3 scripts/release.py --helpが役立ちます。release.pyはPython 3.12でのみテストされています（時代についていきましょう :D）
リリースを作成するには
リリースのバージョン番号を決定します
Blackは、
YY.M.N形式を使用するCalVerバージョン管理標準に従います。そのため、今月中に既にリリースが行われていない限り、
Nは0になります。
例：2022年1月の最初のリリース→
22.1.0release.pyはこれを計算し、標準エラー出力にコピーペーストしやすいようにログを出力します。
CHANGES.mdとドキュメントを編集して最新の変更をバージョン化するPRを作成します。ほとんどの変更を生成するには
python3 scripts/release.py [--debug]を実行します。テンプレートの小見出しは、箇条書きがない場合は手動で削除する必要があります。改善のためのPRは大歓迎です :D
release.pyが失敗した場合は手動で編集します。そうでない場合は、この手順をスキップできます！## Unreleasedヘッダーをバージョン番号に置き換えます。現在のリリースに関する空のセクションをすべて削除します。
(オプション)変更ログを読み直してコピー編集します（例：エントリの移動、タイポの修正、エントリの言い換えなど）。
最後のリリース以降の変更ログのエントリが間違ったセクションに配置されていないことを二重に確認します（例：
git diff <last release> CHANGES.mdを実行）。
PRの例：GH-3139
リリースPRがマージされたら、すべてのCIが完了するまで待ちます。
CIが失敗した場合は、停止して失敗を調査します。通常、リリースを行う前に失敗しているCIを修正したいからです。
-
Choose a tagをクリックし、バージョン番号を入力して、表示されるCreate new tag: YY.M.N on publishオプションを選択します。新しいタグが
mainブランチをターゲットにしていることを確認します。リリースタイトルは空欄のままにすることができます。GitHubはデフォルトでタグ名になります。
現在のリリースの生の変更ログMarkdownを説明欄にコピーペーストします。
GitHub Releaseを公開して、残りの処理を行うリリース自動化をトリガーします。
CIが完了したら、+ commit（git push - レビューなし）して、次のリリース用の新しい空のテンプレートをCHANGES.mdに追加します。（テンプレートは、失敗した場合にrelease.pyからコピーペーストできます）
python3 scripts/release.py --add-changes-template|-a [--debug]失敗した場合は、コピー＆ペーストに戻ってください。
この時点で、基本的に完了です。すべてのリリースワークフローが正常に完了したことを確認することをお勧めしますが、何か失敗した場合にはGitHubから通知を受け取ります。
何かが失敗したとしても、パニックにならないでください。それぞれのワークフローのログと設定ファイルを読んで、修正/解決策を逆算してください。
おめでとうございます！Blackの新しいリリースを成功裏に作成しました。立ち上がって休憩を取りましょう。あなたはそれを mérite します。
重要
リリースアーティファクトがPyPIに到達すると、回帰を示す新しいIssueが報告されることがあります。回帰は良くないものですが、必ずしも修正リリースが必要であることを意味するわけではありません。回帰が深刻で多くのユーザーに影響を与える場合を除き、修正リリースは不要な可能性があります。
最終的には、最善の判断を行い、他のメンテナンス担当者に意見を求めてください。
リリースワークフロー¶
Blackのリリース自動化はすべてGitHub Actionsを使用しています。そのため、すべてのワークフローは、Blackリポジトリの.github/workflowsディレクトリにあるYAMLファイルを使用して構成されています。
これらは、GitHub Releaseの公開によってトリガーされます。
以下は、当社のリリースワークフローの説明です。
PyPIへの公開¶
これは私たちのメインワークフローです。PyPIにアップロードするsdistとホイールをビルドします。ほとんどのユーザーはここからBlackをダウンロードします。3つのジョブグループに分かれています。
sdist + 純粋なホイール¶
この単一のジョブは、buildを使用してsdistと純粋なPythonホイール（つまり、Pythonコードのみを含むホイール）をビルドし、twineを使用してPyPIにアップロードします。これらのアーティファクトは汎用的なもので、Pythonでサポートされているほぼすべてのプラットフォームで使用できます。
mypycホイール（…）¶
私たちは、パフォーマンスを大幅に向上させるために、BlackをCPython C拡張機能にコンパイルするためにmypycを使用しています。mypycでビルドされたホイールは、プラットフォームとPythonのバージョンに固有です。サポートされているプラットフォームはFAQに記載されています。
これらのマトリックスジョブは、多くの環境に対するC拡張機能のビルドという複雑なタスクを処理するcibuildwheelを使用しています。これらのホイールのビルドは遅いので、特定のプラットフォーム（ジョブ名で括弧内に示されている）をビルドする複数のmypycホイールジョブ（そのため「マトリックス」という用語が使用されています）があります。
前のジョブグループと同様に、ビルドされたホイールはtwineを使用してPyPIにアップロードされます。
stableブランチの更新¶
このジョブは実際にはここに属していませんが、他のPyPIジョブが完了した後（このジョブを開始するには、これらが完了する必要があります）、stableブランチを更新することが最も理にかなっています。これにより、リリース後にいつかブランチを更新することを覚えておく必要がなくなります。
現在、このワークフローは@ambvのPyPIアカウントに関連付けられているAPIトークンを使用しています。
実行可能ファイルの公開¶
このワークフローは、PyInstallerを使用して複数のプラットフォーム用のネイティブ実行可能ファイルをビルドします。これにより、ユーザーは自分のプラットフォーム用の実行可能ファイルをダウンロードし、PythonランタイムをインストールせずにBlackを実行できます。
生成されたバイナリは、関連付けられたGitHubリリースに保存されており、IPv4のみでダウンロードできます（GitHubはまだIPv6にアクセスできません😢）。
Docker¶
このワークフローは、DockerのQEMU搭載buildx機能を使用して、公式のBlack Dockerイメージ™のarm64とamd64/x86_64ビルドをアップロードします。
現在、このワークフローは@cooperleesアカウントに関連付けられたAPIトークンを使用しています。
注記
これはmainへのプッシュごとに実行されます。