リリースモデル

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

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

サポート マトリックス

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

計画的なリリースについては、GitHub のリリースに関する問題をご確認ください。

リリースの手順とポリシー

ローリング リリースの場合、プロセスは簡単です。約 2 週間ごとに、Google 内部の Blaze リリースと同じベースラインに合わせて新しいリリースが作成されます。迅速なリリース スケジュールのため、変更内容をローリング リリースにバックポートすることはできません。

LTS リリースの場合は、次の手順とポリシーに沿って行われます。

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

  4. Bazel メンテナンス担当者向けに、Cherry-Pick リクエストの問題を使用した変更をバックポートしました。

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

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

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

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

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

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

    • リリース候補は bazel-discuss で発表されています。Bazel チームは、候補のコミュニティ バグレポートをモニタリングしています。
    • 新しいリリースの阻害要因が特定された場合は、最後のステップに戻り、すべての問題を解決した後に新しいリリース候補を作成します。
    • 最初のリリース候補版の作成後に、リリース ブランチに新しい機能を追加することはできません。

  7. リリースの阻害要因が見つからなければ、リリース候補を公式リリースとしてプッシュする

    • パッチリリースの場合は、最後のリリース候補が公開されてから少なくとも 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 バージョンとの互換性を維持したい場合は、ルールの互換性のページをご覧ください。