リリースモデル

問題を報告する ソースを表示

ナイトリー · 9.2 · 9.1 · 9.0 · 8.7 · 8.6

元のブログ投稿で発表されたように、Bazel 4.0 以降のバージョンでは、ローリング リリースと長期サポート（LTS）リリースの 2 つのリリース トラックがサポートされています。このページでは、Bazel のリリースモデルに関する最新情報について説明します。

サポート マトリックス

LTS リリース	サポート ステージ	最新バージョン	サポートの終了
Bazel 10	ローリング	ローリング リリース ページを確認する	なし
Bazel 9	有効	9.3.1	2028 年 12 月
Bazel 8	メンテナンス	8.8.2	2027 年 12 月
Bazel 7	メンテナンス	7.7.2	2026 年 12 月
Bazel 6	非推奨	6.6.0	2025 年 12 月
Bazel 5	非推奨	5.4.1	2025 年 1 月
Bazel 4	非推奨	4.2.4	2024 年 1 月

すべての Bazel LTS リリースは、GitHub のリリース ページで確認できます。GitHub の「Latest」バッジは、古いバージョンのメンテナンス パッチが最近リリースされた場合でも、常に最新のセマンティック バージョンを指します。

リリースのバージョニング

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 リリースでは、以下の手順とポリシーが適用されます。

1. リリースのベースライン commit を決定します。
   • 新しいメジャー LTS リリースの場合、ベースライン コミットはメイン ブランチの HEAD です。
   • マイナー リリースまたはパッチリリースの場合は、同じ LTS リリースの現在の最新バージョンの HEAD がベースライン コミットになります。
2. ベースライン コミットから release-<version> という名前のリリース ブランチを作成します。
3. PR を介して変更をリリース ブランチにバックポートします。
   • コミュニティは、関連する GitHub の問題または PR に「@bazel-io flag」と返信して、リリースをブロックする可能性があるものとしてマークすることで、特定の commit をバックポートすることを提案できます。Bazel チームは、それらをトリアージして、commit をバックポートするかどうかを決定します。
   • メインブランチの下位互換性のある commit のみがバックポートできます。マージの競合を解決するための追加のマイナー変更は許容されます。

4. Bazel メンテナー向けの Cherry-Pick Request Issue を使用して変更をバックポートします。

   • Bazel のメンテナーは、特定の commit をリリース ブランチにチェリーピックするようリクエストできます。このプロセスは、GitHub でチェリーピック リクエストを作成することから始まります。次にその方法をご紹介します。

     1. チェリーピック リクエストを開きます。
     2. リクエストの詳細を入力します。
        • タイトル: リクエストの簡潔でわかりやすいタイトルを入力します。
        • Commit ID(s): cherry-pick する commit の ID を入力します。複数の commit がある場合は、カンマで区切ります。
        • [Category]: リクエストのカテゴリを指定します。
        • レビュー担当者: 複数のレビュー担当者を指定する場合は、GitHub ID をカンマで区切ります。
     3. マイルストーンを設定する
        • [マイルストーン] セクションを見つけて、設定をクリックします。
        • 該当する X.Y.Z リリース ブロッカーを選択します。このアクションにより、チェリーピック bot がトリガーされ、「release-X.Y.Z」ブランチのリクエストが処理されます。
     4. 問題を送信する
        • すべての詳細を入力し、マイルストーンを設定したら、問題を送信します。

   • チェリーピック ボットがリクエストを処理し、コミットがチェリーピックの対象となるかどうかを通知します。commit が cherry-pickable である場合、つまり commit の cherry-pick 中にマージの競合が発生しない場合、bot は新しい pull リクエストを作成します。pull リクエストが Bazel チームのメンバーによって承認されると、commit がチェリーピックされ、リリース ブランチにマージされます。完了したチェリーピック リクエストの視覚的な例については、こちらの例をご覧ください。

5. リリース ブロッカーを特定し、リリース ブランチで見つかった問題を修正します。

   • リリース ブランチは、Bazel CI のpostsubmitとダウンストリーム テスト パイプラインで同じテストスイートを使用してテストされます。Bazel チームは、リリース ブランチのテスト結果をモニタリングし、見つかった回帰を修正します。

6. 既知のリリース ブロッカーがすべて解決されたら、リリース ブランチから新しいリリース候補版を作成します。

   • リリース候補版は bazel-discuss で発表され、Bazel チームは候補版に関するコミュニティのバグレポートをモニタリングします。
   • 新しいリリース ブロッカーが特定された場合は、最後のステップに戻り、すべての問題を解決してから新しいリリース候補版を作成します。
   • 最初のリリース候補版が作成された後は、リリース ブランチに新機能を追加することはできません。チェリーピックは、重要な修正のみに限定されます。チェリーピックが必要な場合、リクエスト元は次の質問に回答する必要があります。この変更が重要な理由と、それによって得られるメリットは何ですか？この変更によって回帰が発生する可能性はどの程度ですか？

7. リリースを妨げる問題がこれ以上見つからない場合は、リリース候補版を公式リリースとしてプッシュします。

   • パッチリリースの場合は、最後のリリース候補版がリリースされてから 2 営業日以上経過した後にリリースをプッシュします。
   • メジャー リリースとマイナー リリースの場合、最後のリリース候補版がリリースされてから 2 営業日後にリリースをプッシュします。ただし、最初のリリース候補版がリリースされてから 1 週間以上経過している必要があります。
   • リリースは、翌日が営業日である日にのみプッシュされます。
   • リリースは bazel-discuss で発表され、Bazel チームは新しいリリースに関するコミュニティのバグレポートをモニタリングして対処します。

回帰を報告する

新しい Bazel リリース、リリース候補版、または HEAD の Bazel で回帰が見つかった場合は、GitHub でバグを報告してください。Bazelisk を使用して、原因となる commit を二分し、この情報をバグレポートに含めることができます。

たとえば、Bazel 6.1.0 ではビルドが成功するものの、6.2.0 の 2 番目のリリース候補版では失敗する場合、次のようにして bisect を実行できます。

bazelisk --bisect=6.1.0..release-6.2.0rc2 build //foo:bar

BAZELISK_SHUTDOWN または BAZELISK_CLEAN 環境変数を設定して、対応する bazel コマンドを実行し、問題を再現するために必要な場合はビルド状態をリセットできます。詳細については、Bazelisk のbisect 機能に関するドキュメントをご覧ください。

bisect 機能を使用するには、Bazelisk を最新バージョンにアップグレードしてください。

ルールの互換性

ルールの作成者で、異なる Bazel バージョンとの互換性を維持したい場合は、ルールの互換性ページをご覧ください。