リリースモデル

問題を報告する ソースを表示 ナイトリー · 8.0 · 7.4 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

サポート マトリックス

LTS リリース サポート ステージ 最新バージョン サポートの終了
Bazel 8 ローリング ローリング リリース ページを確認する なし
Bazel 7 有効 7.4.1 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 か月ごとにリリースされる予定です。
  • パッチ リリース: アクティブ ステージとメンテナンス ステージの LTS リリースの新しいパッチ バージョンは、重大なバグ修正のためにオンデマンドでリリースされる予定です。
  • Bazel LTS リリースは、メンテナンス ステージに 2 年間滞在した後、非推奨のステージに移行します。

予定されているリリースについては、GitHub のリリースに関する問題を確認してください。

リリース手順とポリシー

ローリング リリースのプロセスは簡単です。Google 内部の Blaze リリースと同じベースラインに合わせて、約 2 週間ごとに新しいリリースが作成されます。リリース スケジュールが短いため、ローリング リリースへの変更のバックアップは行いません。

LTS リリースの場合は、次の手順とポリシーが適用されます。

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

  4. Bazel のメンテナー向けのチェリーピック リクエストの問題を使用して、変更をバックポートします。

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

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

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

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

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

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

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

  7. リリースのブロック要因が他に見つからない場合は、リリース候補版を公式リリースとしてプッシュします。

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

回帰を報告する

新しい Bazel リリース、リリース候補版、または Bazel at HEAD でリグレッションが見つかった場合は、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 機能に関するドキュメントをご覧ください。

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

ルールの互換性

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