元のブログ投稿で発表したように、Bazel 4.0 以降のバージョンでは、ローリング リリースと長期サポート（LTS）リリースの 2 つのリリース トラックがサポートされています。このページでは、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 からローリング リリースを公開します。
- Active: このメジャー バージョンは、現在アクティブな 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 のリリースに関する問題をご確認ください。
サポート マトリックス
| LTS リリース | サポート ステージ | 最新バージョン | サポートの終了 |
|---|---|---|---|
| Bazel 7 | ローリング | GitHub リリース ページを確認する | なし |
| Bazel 6 | 有効 | 6.4.0 | 2025 年 12 月 |
| Bazel 5 | メンテナンス | 5.4.1 | 2025 年 1 月 |
| Bazel 4 | メンテナンス | 4.2.4 | 2024 年 1 月 |
すべての Bazel リリースは、GitHub のリリース ページで確認できます。
リリース手順とポリシー
ローリング リリースの場合、プロセスは簡単です。約 2 週間ごとに、Google 内部の Blaze リリースと同じベースラインに沿って新しいリリースが作成されます。リリース スケジュールが早いため、ローリング リリースに変更をバックポートすることはありません。
LTS リリースでは、次の手順とポリシーが適用されます。
- リリースのベースライン commit を決定します。
- 新しいメジャー LTS リリースの場合、ベースライン コミットはメインブランチの HEAD です。
- マイナー リリースまたはパッチ リリースの場合、ベースライン コミットは、同じ LTS リリースの現在の最新バージョンの HEAD です。
- ベースライン コミットから
release-<version>という名前のリリース ブランチを作成します。 - PR を介して変更をリリース ブランチにバックポートします。
- コミュニティは、関連する GitHub の問題や PR に「
@bazel-io flag」と返信して、特定のコミットをバックポートすることを提案し、潜在的なリリース ブロッカーとしてマークできます。Bazel チームはそれらをトリアージし、コミットをバックポートするかどうかを決定します。 - メインブランチの下位互換性のある commit のみバックポートできます。マージの競合を解決するための追加のマイナー変更は許容されます。
- コミュニティは、関連する GitHub の問題や PR に「
- リリース ブロッカーを特定し、リリース ブランチで見つかった問題を修正します。
- リリース ブランチは、Bazel CI の postsubmit と downstream テスト パイプラインで同じテストスイートを使用してテストされます。Bazel チームはリリースブランチのテスト結果をモニタリングし、見つかった回帰を修正します。
- 既知のリリース ブロッカーがすべて解決されたら、リリース ブランチから新しいリリース候補を作成します。
- リリース候補版は bazel-discuss で発表され、Bazel チームは候補版に関するコミュニティのバグレポートをモニタリングします。
- 新しいリリースのブロッカーが特定された場合は、前の手順に戻り、すべての問題を解決してから新しいリリース候補を作成します。
- 最初のリリース候補が作成された後、リリース ブランチに新しい機能を追加することはできません。
- リリースを妨げる問題がこれ以上見つからなければ、リリース候補版を正式リリースとしてプッシュします。
- パッチ リリースの場合、最後のリリース候補がリリースされてから少なくとも 2 営業日後にリリースをプッシュします。
- メジャー リリースとマイナー リリースの場合、最後のリリース候補がリリースされてから 2 営業日後にリリースをプッシュしますが、最初のリリース候補がリリースされてから 1 週間より早くはプッシュしません。
- リリースは、翌日が営業日である日にのみプッシュされます。
- リリースは bazel-discuss で発表されます。Bazel チームは、新しいリリースに関するコミュニティのバグレポートをモニタリングし、対応します。
回帰を報告する
新しい Bazel リリース、リリース候補、または HEAD の Bazel で回帰が見つかった場合は、GitHub でバグを報告してください。Bazelisk を使用して原因となったコミットを特定し、この情報をバグレポートに含めることができます。
たとえば、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 バージョンとの互換性を維持したい場合は、ルールの互換性のページをご覧ください。