元のブログ投稿でお知らせしたように、Bazel 4.0 以降ではバージョンで 2 つのリリース トラック（ローリング リリースと長期サポート（LTS）リリース）がサポートされています。このページでは、Bazel のリリースモデルに関する最新情報について説明します。
リリースのバージョニング
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 チームは、この LTS リリースにセキュリティ問題と OS 互換性に関する問題の重大なバグの修正のみをバックポートすることを約束します。
- 非推奨: Bazel チームはこのメジャー バージョンのサポートを終了しているため、すべてのユーザーが新しい Bazel LTS リリースに移行する必要があります。
リリースの頻度
Bazel は 2 つのリリース トラックのリリースを定期的に公開しています。
ローリング リリース
- ローリング リリースは Google Blaze リリースと連携して HEAD から約 2 週間ごとにリリースされます。これは、次の Bazel LTS リリースのプレビューです。
- ローリング リリースは互換性のない変更をリリースする可能性があります。互換性を破る変更を行う場合は、互換性のないフラグをおすすめします。互換性のない変更は、下位互換性ポリシーに従う必要があります。
LTS リリース
- メジャー リリース: 新しい LTS リリースは、およそ 12 か月ごとに HEAD から切断される予定です。新しい LTS リリースがリリースされると、すぐに Active ステージに入り、以前の LTS リリースがメンテナンス ステージに入ります。
- マイナー リリース: Active LTS トラックの新しいマイナー バージョンは 2 か月ごとにリリースされる予定です。
- パッチリリース: アクティブステージとメンテナンス ステージの LTS リリースの新しいパッチ バージョンは、重大なバグの修正のためにオンデマンドでリリースされる予定です。
- Bazel LTS リリースは、2 年間のメンテナンス後、非推奨のステージに入ります。
リリースが予定されている場合は、GitHub のリリースに関する問題をご確認ください。
サポート マトリックス
| LTS リリース | サポート ステージ | 最新バージョン | サポートの終了 |
|---|---|---|---|
| Bazel 7 | 連続 | GitHub リリースページを確認する | なし |
| Bazel 6 | 有効 | 6.3.2 | 2025 年 12 月 |
| Bazel 5 | メンテナンス | 5.4.1 | 2025 年 1 月 |
| Bazel 4 | メンテナンス | 4.2.4 | 2024 年 1 月 |
Bazel のすべてのリリースは、GitHub のリリースページにあります。
リリースの手順とポリシー
ローリング リリースの場合、プロセスは簡単です。Google 内部の Blaze リリースと同じベースラインと一致する新しいリリースが約 2 週間ごとに作成されます。即時リリースは予定されているため、ローリング リリースに対する変更はバックポートされません。
LTS リリースでは、以下の手順とポリシーが適用されます。
- リリースのベースライン commit を決定します。
- 新しいメジャー LTS リリースの場合、ベースライン コミットはメインブランチの HEAD になります。
- マイナー リリースまたはパッチリリースの場合、ベースライン commit は、同じ LTS リリースの最新の最新バージョンの HEAD です。
- ベースライン commit から
release-<version>という名前にリリース ブランチを作成します。 - PR を介してリリース ブランチにバックポートする。
- コミュニティは、特定の GitHub の問題や PR について「
@bazel-io flag」に返信して特定のリリースをバックポートするように提案できます。その場合、リリースを阻害するものとして Bazel チームがトリアージし、コミットをバックポートするかどうかを決定します。 - main ブランチでは、下位互換性のある commit のみをバックポートできます。マージの競合を解決するために軽微な変更を加えることもできます。
- コミュニティは、特定の GitHub の問題や PR について「
- リリースの阻害要因を特定し、リリース ブランチで見つかった問題を修正する。
- リリース ブランチは、Bazel CI の postsubmit とダウンストリーム テスト パイプラインで同じテストスイートを使用してテストされます。Bazel チームはリリース ブランチのテスト結果をモニタリングし、見つかった回帰を修正します。
- 既知のリリース ブロッカーがすべて解決したら、リリース ブランチから新しいリリース候補を作成します。
- リリース候補が bazel-discuss で発表されます。Bazel チームはその候補のコミュニティ バグレポートをモニタリングします。
- 新しいリリース ブロッカーが特定されたら、最後のステップに戻って、すべての問題を解決した後、新しいリリース候補を作成します。
- 最初のリリース候補が作成された後、リリース ブランチに新機能を追加することはできません。
- リリースの阻害要因がこれ以上ない場合は、リリース候補を公式リリースとしてプッシュします。
- パッチリリースの場合は、最後のリリース候補がリリースされてから少なくとも 2 営業日後にリリースをプッシュします。
- メジャー リリースとマイナー リリースの場合、リリース候補は最後のリリース候補が発表されてから 2 営業日後（少なくとも 1 週間後）にリリースされます。
- リリースは営業日である翌日にのみプッシュされます。
- このリリースは bazel-discuss で発表されます。Bazel チームは新しいリリースをモニタリングしてコミュニティのバグレポートに対応します。
回帰を報告する
新しい Bazel リリース、リリース候補、または Bazel の回帰で回帰が見つかった場合は、GitHub でバグを報告してください。Bazelisk を使用すると、問題の原因を commit して、バグレポートに情報を含めることができます。
たとえば、ビルドが Bazel 6.1.0 で成功し、6.2.0 の 2 番目のリリース候補で失敗する場合、
bazelisk --bisect=6.1.0..release-6.2.0rc2 build //foo:bar
問題を再現する必要がある場合は、BAZELISK_SHUTDOWN または BAZELISK_CLEAN 環境変数を設定して、対応する bazel コマンドを実行し、ビルド状態をリセットできます。詳細については、Bazelisk のBisect 機能に関するドキュメントをご覧ください。
二等分機能を使用するには、Bazelisk を最新バージョンにアップグレードしてください。
ルールの互換性
ルールの作成者で、異なる Bazel バージョンとの互換性を維持するには、ルールの互換性ページをご覧ください。