リリースモデル

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

元のブログ投稿でお知らせしたように、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 のリリースページで確認できます。

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

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

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

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

ルールの互換性

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