LLVMを公開する方法

はじめに

このドキュメントには、LLVM（サブプロジェクトを含む：例：clang、compiler-rt）を公開するために必要な情報が記載されています。高品質なLLVMビルドをリリースすることは、リリース管理者の責任です。

リリース候補のテスト方法とバイナリパッケージの作成方法に関するドキュメントをお探しの場合は、代わりに新しいリリースを検証する方法を参照してください。

リリースのタイムライン

LLVMは、約6か月ごとのメジャーリリースという時間ベースのスケジュールでリリースされます。メジャーリリースの間に、ドットリリースが行われる場合があります。リリースマネージャーは、コミュニティからのフィードバックに基づいて、ドットリリースを行うかどうか、およびいつ行うかを決定します。通常、安定版ブランチに多数のバグ修正がある場合、または多数のユーザーに影響を与える重大なバグが発見された場合は、ドットリリースを行う必要があります。

特に明記されていない限り、ドットリリースはメジャーリリースと同じ手順に従います。

年間リリーススケジュール

LLVMの年間リリーススケジュールは次のとおりです。これはガイドであり、リリースマネージャーはこれを厳密に守る必要はありません。リリースは火曜日にタグ付けする必要があります。

リリース

おおよその日付

リリースブランチ：偶数リリース

1月の第4火曜日

リリースブランチ：奇数リリース

7月の第4火曜日

X.1.0-rc1

ブランチから3日後。

X.1.0-rc2

ブランチから2週間後。

X.1.0-rc3

ブランチから4週間後

X.1.0-final

ブランチから6週間後

X.1.1

ブランチから8週間後

X.1.2

ブランチから10週間後

X.1.3

ブランチから12週間後

X.1.4

ブランチから14週間後

X.1.5

ブランチから16週間後

X.1.6 (必要な場合)

ブランチから18週間後

リリースプロセスの概要

  • リリーススケジュールをLLVMコミュニティに発表し、ウェブサイトを更新します。これは、-rc1リリースの少なくとも3週間前に行ってください。

  • リリースブランチを作成し、リリースプロセスを開始します。

  • 第1ラウンドのテスト用にリリース候補ソースを送信します。テストは6週間続きます。第1ラウンドのテスト中に見つかった回帰はすべて修正する必要があります。パッチはメインラインからリリースブランチにマージされます。また、すべての機能はこの期間中に完了する必要があります。第1ラウンドのテストの終了時に完了していない機能は、リリースから削除または無効化されます。

  • 2番目のリリース候補ソースを生成して送信します。このテストフェーズ中に見つかった_重大な_バグのみが修正されます。マージされたパッチによって導入されたバグは修正されます。その場合は、3回目のテストが必要です。

  • リリースノートが更新されます。

  • 最後に、リリース！

  • バグ修正リリーススケジュールをLLVMコミュニティに発表し、ウェブサイトを更新します。

  • X.1.5またはX.1.6（必要な場合）まで、2週間ごとにバグ修正リリースを行います。

リリースプロセス

リリース管理タスク

このセクションでは、リリースプロセスを開始するために行う必要があるいくつかの管理タスクについて説明します。具体的には、次の作業が含まれます。

  • バージョン番号の更新、

  • リリースブランチの作成、および

  • リリースチームがテストを開始するためのリリース候補のタグ付け。

リリースブランチの作成

次の手順を使用してGitトランクをブランチします

  1. リリースブランチの作成が差し迫っていることを開発者に伝え、ビルドを壊す可能性のあるパッチ（例：新機能、進行中の作業の大規模なパッチ、タイプシステムのオーバーホール、エキサイティングな新しいTableGen機能など）をコミットしないようにしてください。

  2. ナイトリーテスターとビルドボットの結果を調べて、現在のgitトランクが適切な状態にあることを確認します。

  3. トランクのバージョンをN.0.0gitに上げ、コミットにllvmorg-N-initのタグを付けます。Xがリリースされるバージョンである場合、NはX + 1です。

$ git tag -sa llvmorg-N-init

  1. トランクのリリースノートをクリアします。

  2. バージョンバンプ前の最後の既知の良好なリビジョンからリリースブランチを作成します。ブランチの名前はrelease/X.xで、Xはメジャーバージョン番号、xは文字xです。

  3. 新しく作成されたリリースブランチで、すぐにバージョンをX.1.0gitに上げます（Xはブランチのメジャーバージョンです）。

  4. すべてのタグとブランチは、llvm/llvm-projectとllvm/llvm-test-suiteの両方のリポジトリに作成する必要があります。

LLVMバージョンの更新

LLVMリリースブランチを作成した後、llvm/utils/release/bump-version.pyにあるスクリプトを使用してリリースブランチのバージョンを更新します。

LLVMリリース候補のタグ付け

リリース候補にタグを付ける

$ git tag -sa llvmorg-X.Y.Z-rcN

事前にパッケージ化されたソースtarballは、GitHubの「Release Sources」ワークフローによって自動的に生成されます。このワークフローは、すべてのリリースタルボールとアーティファクトアテステーションを含むアーティファクトを作成します。リリースマネージャーは、アーティファクトをダウンロードし、tarballを検証し、署名してから、リリースページにアップロードする必要があります。

$ unzip artifact.zip
$ gh auth login
$ for f in *.xz; do gh attestation verify --owner llvm $f && gpg -b $f; done

Tarball、リリースバイナリ、またはその他のリリースアーティファクトは、GitHubにアップロードする必要があります。これは、utils/releaseにあるgithub-upload-release.pyスクリプトを使用して実行できます。

$ github-upload-release.py upload --token <github-token> --release X.Y.Z-rcN --files <release_files>

バイナリディストリビューションのビルド

バイナリディストリビューションを作成するには、こちらの指示に従う必要があります。

そのプロセスでは、Release + AssertsとReleaseの両方のビルドが実行されますが、アップロード用にパックされるのはReleaseビルドのみです。Release + Asserts sysroot（通常はfinal/Phase3/Release+Asserts/llvmCore-3.8.1-RCn.install/の下）を使用して、テストスイートとランタイムベンチマークを実行し、重大な問題が発生していないことを確認する必要があります。コンパイル時ベンチマークには、リリースバージョンを使用してください。

必要なツールの最小バージョンはこちらです。

リリースの認定基準

公式のリリース認定基準はありません。リリースの準備ができた時期を判断するのは、リリースマネージャー次第です。リリースマネージャーは、コミュニティテストの結果、未解決のバグの数、およびリリースを行うかどうかを決定する際の回帰の数に注意を払う必要があります。

コミュニティは時間に基づくリリースを重視しているため、重大な問題が残っていない限り、リリースを長く遅らせるべきではありません。ほとんどの場合、リリースをブロックするのに十分な重大なバグの種類は、以前のリリースからの大きな回帰だけです。

公式テスト

コミュニティの少数の開発者は、リリース候補の検証に専念しており、各アーキテクチャの公式リリーステスターになることを志願しています。

これらは、公式バイナリをテスト、生成、およびサーバーにアップロードするものであり、リリースを進めるために_必要な_最小限のテストになります。

これは明らかにすべてのOSとディストリビューションをカバーするわけではないため、追加のコミュニティ検証が重要です。ただし、リリース前にコミュニティからの情報が得られない場合、報告されたすべてのバグは次の安定版リリースに持ち越す必要があります。

公式リリース マネージャーは次のとおりです.

公式リリーステスターは、コミュニティからボランティアで参加し、ターゲット/ OSのバイナリを一貫して検証およびリリースしています。連絡するには、ディスカッションフォーラム（プロジェクトインフラストラクチャ-リリーステスター）に投稿する必要があります。

公式テスターのリストは、LLVMリポジトリのRELEASE_TESTERS.TXTファイルにあります。

コミュニティテスト

すべてのテストが完了し、適切なバグが報告されたら、リリース候補tarballがウェブサイトに掲載され、LLVMコミュニティに通知されます。

すべてのLLVM開発者は、次のいずれかの方法でリリースをテストすることをお勧めします

  1. llvm-X.Y、llvm-test-X.Y、および適切なclangバイナリをダウンロードします。LLVMをビルドします。make checkと完全なLLVMテストスイート（make TEST=nightly report）を実行します。

  2. llvm-X.Y、llvm-test-X.Y、およびclangのソースコードをダウンロードします。すべてをコンパイルします。 make check とLLVMテストスイート全体（make TEST=nightly report）を実行します。

  3. llvm-X.Y、llvm-test-X.Y、および適切なclangバイナリをダウンロードします。それを使用して、プラットフォーム向けのプログラム全体（例：Chromium、Firefox、Apache）をビルドします。

  4. llvm-X.Y、llvm-test-X.Y、および適切なclangバイナリをダウンロードします。それを使用して*独自の*プログラムをビルドし、適合性とパフォーマンスの低下を確認します。

  5. プラットフォームが公式にサポートされているプラットフォームと*異なる*場合、リリースプロセスを実行し、そのアーキテクチャの公式リリーステスターによって報告されていない場合にのみエラーを報告します。

また、OSディストリビューションのリリース管理者は、すべてリリースの最初の候補でパッケージをテストし、GitHubに*新しい*エラーを報告することをお勧めします。バグが、ディストリビューション独自のビルドではなく、パッチが適用されていないアップストリームバージョンのリリース候補で再現できる場合、優先度はリリースブロッカーである必要があります。

最初のテストラウンドでは、2番目のリリース候補がタグ付けされる前に、すべての低下が修正されている必要があります。

後続の段階では、テストは、以前にマージされたバグ修正によって新しい大きな問題が発生していないことを確認するためだけに行われます。 *これは、追加の無関係なバグを解決する時ではありません！* パッチがマージされていない場合、リリースは準備完了と判断され、リリース管理者は次の段階に進むことができます。

低下の報告

テスト中に見つかったすべての低下（上記の基準に従って）は、GitHubのバグに記入し、リリースのマイルストーンに追加する必要があります。

バグを再現できない場合、またはブロッカーでなくなった場合は、マイルストーンから削除する必要があります。デバッグは継続できますが、トランク上で行います。

バックポートリクエスト

安定版ブランチへのバックポートをリクエストする手順は、こちらにあります。

リリースのバグレポートのトリアージ

このセクションでは、バグレポートをトリアージする方法について説明します

  1. 「リリースステータス」githubプロジェクトに追加されていないリリースのマイルストーンを持つバグを検索します

    https://github.com/llvm/llvm-project/issues?q=is%3Aissue+milestone%3A%22LLVM+14.0.5+Release%22+no%3Aproject+

    このクエリで14.0.5を、対象とするリリースのマイルストーンのバージョンに置き換えます。

    これらのバグを「リリースステータス」プロジェクトに追加します。

  2. リリースステータスプロジェクトに移動して、リリースが検討されているバグのリストを確認します。

  3. 各バグを確認し、最初にメインで修正されているかどうかを確認します。修正されている場合は、ステータスを「プルリクエストが必要」に更新し、/ cherry-pickまたは/ branchコメントを使用して修正のプルリクエストを作成します（まだ作成されていない場合）。

  4. バグが修正され、バックポートするためのプルリクエストが作成されている場合は、ステータスを「レビューが必要」に更新し、知識のあるレビュアーに通知します。通常は、Phabricatorでパッチを承認した人に通知しますが、適切なレビュアーは誰であるかについて、最善の判断を下すことができます。レビュアーを特定したら、問題を割り当て、コメントでメンションし（つまり@username）、パッチのバックポートが安全かどうかを尋ねます。また、バグを自分でレビューして、リリースブランチにコミットするための要件を満たしていることを確認する必要があります。

  5. バグがレビューされたら、release：reviewedラベルを追加し、問題のステータスを「マージが必要」に更新します。問題に関連付けられたプルリクエストを確認します。すべてのテストに合格した場合は、プルリクエストをマージできます。そうでない場合は、問題にコメントを追加して、誰かに障害を確認するように依頼します。

  6. プルリクエストがマージされたら、スクリプトllvm/utils/git/sync-release-repo.shを使用して公式リリースブランチにプッシュします。

    次に、問題にコメントを追加して、修正がリリースブランチからのgitハッシュとともにマージされたことを示します。 release：mergedラベルを問題に追加して、閉じます。

リリース パッチ ルール

以下は、リリースブランチへのパッチ適用に関するルールです

  1. リリースブランチに適用されるパッチは、リリース管理者、公式リリーステスター、またはリリース管理者の承認を得たコードオーナーのみが適用できます。

  2. リリース管理者は、パッチを承認する前にコードオーナーから承認を得ることが推奨されますが、必須ではありません。コードオーナーがいない場合、またはコードオーナーに連絡できない場合は、リリース管理者はパッチレビュアーまたはその分野で活動している他の開発者に承認を求めることができます。

  3. *RC1より前* パッチは、バグ修正、重要な最適化の改善、またはブランチが作成される前に開始された機能の完了に限定する必要があります。すべてのフェーズと同様に、リリース管理者とコードオーナーは、侵襲的すぎると見なされるパッチを拒否できます。

  4. *RC2より前* パッチは、バグ修正、または非常に安全であると判断されたバックエンド固有の改善に限定する必要があります。

  5. *RC3 /最終メジャーリリースより前* パッチは、重大なバグまたは低下に限定する必要があります。

  6. *バグ修正リリース* パッチは、バグ修正、または非常に安全で重要なパフォーマンスの向上に限定する必要があります。パッチは、以前のメジャーリリースとのAPIとABIの両方の互換性を維持する必要があります。

リリースの最終タスク

リリースプロセスの最終段階には、「最終」リリースブランチのタグ付け、リリースを参照するドキュメントの更新、およびデモページの更新が含まれます。

ドキュメントの更新

リリースブランチのドキュメントを確認し、最新の状態であることを確認します。「リリースノート」は、新機能、バグ修正、新しい既知の問題、およびサポートされているプラットフォームのリストの変更を反映するように更新する必要があります。「はじめに」は、Subversionから入手できる新しいリリースバージョン番号タグと、基本的なシステム要件の変更を反映するように更新する必要があります。

LLVM最終リリースのタグ付け

最終リリースのソースにタグを付けます

$ git tag -sa llvmorg-X.Y.Z
$ git push https://github.com/llvm/llvm-project.git llvmorg-X.Y.Z

LLVM Webサイトの更新

リリースアナウンスメントが送信される前に、Webサイトを更新する必要があります。すべきことは次のとおりです

  1. GitHubからwww-releasesモジュールをチェックアウトします。

  2. releasesディレクトリに新しいサブディレクトリX.Y.Zを作成します。

  3. llvm/docsファイルとLICENSE.txtファイルをこの新しいディレクトリにコピーしてコミットします。

  4. releases/download.htmlファイルを、GitHub上のリリースバイナリへのリンクで更新します。

  5. releases/index.htmlを新しいリリースで更新し、リリースドキュメントにリンクします。

  6. www-releasesリポジトリに変更をプッシュした後、管理者アクセス権を持つ誰かがprereleases-origin.llvm.orgにログインし、新しい変更を手動で/ data / www-releases /にプルする必要があります。これは、Webサイトが提供される場所です。

  7. 最後に、llvm-wwwリポジトリをチェックアウトし、メインページ（index.htmlとサイドバー）を更新して、新しいリリースとリリースアナウンスメントを指すようにします。

リリースの発表

すべてのリリース作業が完了したら、発表カテゴリに新しい投稿を作成します。 X.1.0リリースの場合は、投稿にリリースノートへのリンクを含めるようにしてください。 X.1.1以降のリリースの場合は、このコマンドを使用して変更ログを生成し、投稿に追加します。

$ git log --format="- %aN: [%s (%h)](https://github.com/llvm/llvm-project/commit/%H)" llvmorg-X.1.N-1..llvmorg-X.1.N

リリースが発表されたら、llvmホームページ（llvm-wwwリポジトリから）の「リリースメール」セクションにアナウンスへのリンクを追加します。