元のブログ投稿でお知らせしたように、Bazel 4.0 以降のバージョンでは、ローリング リリースと長期サポート(LTS)リリースの 2 つのリリース トラックがサポートされています。このページでは、Bazel のリリースモデルに関する最新情報について説明します。
サポート マトリックス
LTS リリース | サポート ステージ | 最新バージョン | サポートの終了 |
---|---|---|---|
Bazel 8 | ローリング | ローリング リリースのページを確認する | なし |
Bazel 7 | アクティブ | 7.1.2 | 2026 年 12 月 |
Bazel 6 | メンテナンス | 6.5.0 | 2025 年 12 月 |
Bazel 5 | メンテナンス | 5.4.1 | 2025 年 1 月 |
Bazel 4 | 非推奨 | 4.2.4 | 2024 年 1 月 |
すべての Bazel LTS リリースは、GitHub のリリースページで確認できます。
リリースのバージョニング
Bazel は、major.minor.patch セマンティック バージョニング スキームを使用します。
- メジャー リリースには、以前のリリースと下位互換性のない機能が含まれています。Bazel のメジャー バージョンは LTS リリースです。
- マイナー リリースには、メインブランチからバックポートされた下位互換性のあるバグの修正と機能が含まれます。
- パッチリリースには重要なバグの修正が含まれています。
プレリリース版の場合は、次のメジャー バージョン番号にハイフンと日付の接尾辞が付加されます。
たとえば、各タイプの新しいリリースの場合、バージョン番号は次のようになります。
- メジャー: 6.0.0
- マイナー: 6.1.0
- パッチ: 6.1.2
- リリース前: 7.0.0-pre.20230502.1
サポート ステージ
Bazel のメジャー バージョンごとに、次の 4 つのサポート ステージがあります。
- ローリング: このメジャー バージョンはまだプレリリース版です。Bazel チームは HEAD からローリング リリースを公開しています。
- 有効: このメジャー バージョンは、現在アクティブな LTS リリースです。Bazel チームは、重要な機能とバグの修正をマイナー リリースにバックポートしています。
- メンテナンス: このメジャー バージョンは、メンテナンス モードの古い LTS リリースです。Bazel チームは、セキュリティの問題と OS の互換性の問題に関する重要なバグの修正のみを、この LTS リリースにバックポートすることを約束します。
- 非推奨: Bazel チームは、このメジャー バージョンのサポートを終了しました。すべてのユーザーは、新しい Bazel LTS リリースに移行する必要があります。
リリースの頻度
Bazel では、2 つのリリース トラックのリリースを定期的に公開しています。
ローリング リリース
- ローリング リリースは Google Blaze リリースと連携し、2 週間ごとに HEAD からリリースされます。これは、次の Bazel LTS リリースのプレビューです。
- ローリング リリースでは、互換性のない変更がリリースされることがあります。互換性のないフラグは、互換性を破る変更に推奨されます。互換性のない変更をロールアウトする場合は、下位互換性に関するポリシーに従ってください。
LTS リリース
- メジャー リリース: 新しい LTS リリースは約 12 か月ごとに HEAD からカットされる予定です。新しい LTS リリースが公開されると、すぐにアクティブ ステージに入り、以前の LTS リリースはメンテナンス ステージに入ります。
- マイナー リリース: アクティブ LTS トラックの新しいマイナー バージョンは、2 か月に 1 回リリースされる予定です。
- パッチリリース: アクティブとメンテナンスのステージにある LTS リリースの新しいパッチ バージョンは、重大なバグの修正のためにオンデマンドでリリースされる予定です。
- Bazel LTS リリースは、2 年間メンテナンス ステージの状態になった後、非推奨ステージに入ります。
計画的なリリースについては、GitHub のリリースに関する問題をご確認ください。
リリースの手順とポリシー
ローリング リリースの場合、プロセスは簡単です。約 2 週間ごとに、Google 内部の Blaze リリースと同じベースラインに合わせて新しいリリースが作成されます。迅速なリリース スケジュールのため、変更内容をローリング リリースにバックポートすることはできません。
LTS リリースの場合は、次の手順とポリシーに沿って行われます。
- リリースのベースライン commit を決定します。
- 新しいメジャー LTS リリースの場合、ベースライン commit はメインブランチの HEAD です。
- マイナーリリースまたはパッチリリースの場合、ベースライン commit は、同じ LTS リリースの現在の最新バージョンの HEAD です。
- ベースライン commit から、
release-<version>
という名前のリリース ブランチを作成します。 - PR を介してリリース ブランチに変更をバックポートします。
- コミュニティは、関連する GitHub の問題または PR で「
@bazel-io flag
」と返信してリリース ブロッカーの可能性を示すことで、特定の commit をバックポートすることを提案できます。Bazel チームはそれらをトリアージして、コミットをバックポートするかどうかを決定します。 - バックポートできるのはメインブランチでの下位互換性のある commit のみです。マージの競合を解決するための追加の軽微な変更が許容されます。
- コミュニティは、関連する GitHub の問題または PR で「
Bazel メンテナンス担当者向けに、Cherry-Pick リクエストの問題を使用した変更をバックポートしました。
Bazel のメンテナンス担当者は、リリース ブランチへの特定の commit の選択をリクエストできます。このプロセスは、GitHub でチェリーピック リクエストを作成することで開始されます。次にその方法をご紹介します。
- チェリーピック リクエストを開きます。
- リクエストの詳細を入力します。
- タイトル: 簡潔でわかりやすいタイトルをリクエストのものにします。
- commit ID: 選択する commit の ID を入力します。commit が複数ある場合は、カンマで区切ってください。
- カテゴリ: リクエストのカテゴリを指定します。
- レビュアー: 複数のレビュアーの場合は、GitHub ID をカンマで区切ってください。
- マイルストーンを設定する
- [マイルストーン] で設定をクリックします。
- 適切な X.Y.Z リリース ブロッカーを選択します。このアクションにより、チェリーピック bot がトリガーされ、「release-X.Y.Z」ブランチのリクエストを処理します。
- 問題を送信する
- 詳細情報をすべて入力し、ミーストーンを設定したら、問題を送信します。
チェリーピック bot はリクエストを処理し、commit がチェリーピックの条件を満たしているかどうかを通知します。commit が選別可能な場合、つまり commit の選別中にマージの競合が発生しない場合、bot は新しい pull リクエストを作成します。pull リクエストが Bazel チームのメンバーによって承認されると、commit が選択されてリリース ブランチにマージされます。完了した選択リクエストの視覚的な例については、こちらの例をご覧ください。
リリースの阻害要因を特定し、リリース ブランチで見つかった問題を修正します。
- リリース ブランチは、Bazel CI の postsubmit とダウンストリーム テスト パイプラインで同じテストスイートを使用してテストされます。Bazel チームは、リリース ブランチのテスト結果をモニタリングし、見つかった回帰を修正します。
既知のリリース ブロッカーがすべて解決されたら、リリース ブランチから新しいリリース候補版を作成します。
- リリース候補は bazel-discuss で発表されています。Bazel チームは、候補のコミュニティ バグレポートをモニタリングしています。
- 新しいリリースの阻害要因が特定された場合は、最後のステップに戻り、すべての問題を解決した後に新しいリリース候補を作成します。
- 最初のリリース候補版の作成後に、リリース ブランチに新しい機能を追加することはできません。
リリースの阻害要因が見つからなければ、リリース候補を公式リリースとしてプッシュする
- パッチリリースの場合は、最後のリリース候補が公開されてから少なくとも 2 営業日後にリリースを push します。
- メジャー リリースとマイナー リリースの場合、最後のリリース候補の発表から 2 営業日後、ただし最初のリリース候補の発表から 1 週間以上経ってからリリースを push します。
- リリースは、翌日が営業日である日に push されます。
- リリースは bazel-discuss で発表されています。Bazel チームは、新しいリリースのコミュニティ バグレポートをモニタリングし、対処しています。
回帰を報告する
新しい Bazel リリース、リリース候補版、または HEAD の Bazel で回帰が見つかった場合は、GitHub でバグを報告してください。Bazelisk を使用して問題の原因の commit を分断し、この情報をバグレポートに追加できます。
たとえば、ビルドが Bazel 6.1.0 で成功し、2 番目のリリース候補版 6.2.0 で失敗した場合は、次のように bisect を実行します。
bazelisk --bisect=6.1.0..release-6.2.0rc2 build //foo:bar
問題を再現する必要がある場合は、BAZELISK_SHUTDOWN
または BAZELISK_CLEAN
環境変数を設定して、対応する bazel コマンドを実行し、ビルド状態をリセットできます。詳細については、Bazelisk の bisect 機能のドキュメントをご覧ください。
bisect 機能を使用するには、Bazelisk を最新バージョンにアップグレードしてください。
ルールの互換性
ルール作成者が Bazel バージョンとの互換性を維持したい場合は、ルールの互換性のページをご覧ください。