リリースモデル

問題を報告 ソースを表示

元のブログ投稿でお知らせしたように、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 リリースはメンテナンス ステージに入ります。
  • マイナー リリース: Active 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 リリースの場合、次の手順とポリシーが適用されます。

  1. リリースのベースライン commit を決定します。
    • 新しい LTS メジャー リリースの場合、ベースライン commit はメインブランチの HEAD になります。
    • マイナーまたはパッチリリースの場合、ベースライン commit は同じ LTS リリースの現在の最新バージョンの HEAD になります。
  2. ベースライン commit から release-<version> という名前でリリース ブランチを作成します。
  3. PR 経由で変更をリリース ブランチにバックポートします。
    • コミュニティは、関連する GitHub の問題または PR で「@bazel-io flag」と返信し、リリース ブロッカーの可能性があるものとしてマークすることで、特定の commit をバックポートすることを提案できます。Bazel チームは、該当する commit を選別し、commit をバックポートするかどうかを決定します。
    • バックポートできるのは、メインブランチでの下位互換性のある commit のみです。マージの競合を解決するためのマイナーな変更は許容されます。
  4. リリースの阻害要因を特定し、リリース ブランチで見つかった問題を修正します。
    • リリース ブランチは、Bazel CI の postsubmitダウンストリーム テスト パイプラインで同じテストスイートを使用してテストされます。Bazel チームは、リリース ブランチのテスト結果をモニタリングし、検出されたリグレッションを修正します。
  5. 既知のリリース ブロッカーがすべて解決されたら、リリース ブランチから新しいリリース候補を作成します。
    • リリース候補版は bazel-discuss で発表されます。Bazel チームは、その候補のコミュニティ バグレポートをモニタリングします。
    • 新しいリリース ブロッカーを特定した場合は、最後の手順に戻り、すべての問題を解決した後に新しいリリース候補を作成します。
    • 最初のリリース候補を作成した後に、リリース ブランチに新機能を追加することはできません。
  6. これ以上リリース ブロッカーが見つからない場合は、リリース候補版を公式リリースとしてプッシュします。
    • パッチリリースの場合は、最後のリリース候補版がリリースされてから 2 営業日以上後にリリースをプッシュします。
    • メジャー リリースとマイナー リリースの場合は、最後のリリース候補版の公開から 2 営業日後(ただし、最初のリリース候補版の公開から 1 週間以内)をプッシュします。
    • リリースは、翌日が営業日にのみプッシュされます。
    • リリースは bazel-discuss で発表されます。Bazel チームは、新しいリリースに関するコミュニティのバグレポートをモニタリングし、対処しています。

回帰を報告する

新しい Bazel リリース、リリース候補版、あるいは Bazel の回帰を HEAD で見つけた場合は、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 バージョンとの互換性を維持するには、ルールの互換性のページをご覧ください。