リリースモデル

<ph type="x-smartling-placeholder"></ph> 問題を報告する をご覧ください。 ソースを表示 夜間 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

元のブログでお知らせしたとおり 投稿、Bazel 4.0 以降では次の 2 つのリリース トラックがサポートされています。ローリング トラック LTS リリースの両方に対応していますこのページでは、Google Cloud 向けの Bazel のリリースモデルに関する情報を確認できます。

サポート マトリックス

LTS リリース サポート ステージ 最新バージョン サポートの終了
Bazel 8 ローリング ローリング リリースのページを確認する なし
Bazel 7 有効 7.3.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 リリースについては、リリースをご覧ください。 のページをご覧ください。

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

Bazel は major.minor.patch セマンティックを使用しています バージョニングスキーム。

  • メジャー リリースに下位互換性のない機能が含まれている おすすめします。Bazel の各メジャー バージョンは LTS リリースです。
  • マイナー リリースには、下位互換性のあるバグ修正と機能が含まれています。 メインブランチからバックポートされます
  • パッチリリースには、重大なバグの修正が含まれています。

プレリリース版は、先頭にハイフンと date サフィックスを次のメジャー バージョン番号に付加します。

たとえば、各タイプの新しいリリースのバージョン番号は次のようになります。

  • メジャー: 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 のプレビューです なります。
  • ローリング リリースにより、互換性のない変更が提供される場合があります。互換性のないフラグは、 重大な互換性を破る変更、互換性のない変更のロールアウトに推奨 Google の下位互換性を維持 に関するポリシーに準拠する必要があります

LTS リリース

  • メジャー リリース: 新しい LTS リリースは、HEAD からおおむねカットされます。 ごと 12 か月。新しい LTS リリースがリリースされると、すぐにアクティブ リリースに入ります。 以前の LTS リリースはメンテナンス ステージに入ります。
  • マイナー リリース: Active LTS トラックの新しいマイナー バージョンのリリースが予定されています。 2 か月に 1 回リリースされます。
  • パッチリリース: Active での LTS リリースと 重大なバグに対しては、メンテナンス ステージがオンデマンドでリリースされる予定です。 あります。
  • Bazel LTS リリースは、 2 年間のメンテナンス ステージ。

予定されているリリースについては、リリース 問題 公開されています。

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

ローリング リリースの場合、プロセスは単純で、約 2 週間に 1 回、 Google 社内チームと同じベースラインに沿って Blaze のリリース。リリース スケジュールは迅速であるため、変更をバックポートすることはできません。 ロールアウトされます。

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

  1. リリースのベースライン commit を決定します。
    • 新しい LTS メジャー リリースの場合、ベースライン commit はメインの されます。
    • マイナー リリースまたはパッチ リリースの場合、ベースラインの commit は 同じ LTS リリースの最新バージョンをアップデートする必要があります。
  2. ベースラインから release-<version> という名前のリリース ブランチを作成します。 できます。
  3. PR 経由で変更をリリース ブランチにバックポートします。
    • コミュニティが返信することで、特定の commit をバックポートすることを提案できます。 「@bazel-io flag」GitHub に関連する問題や PR に登録して、潜在的な問題としてマークを付ける Bazel チームはブロッカーをトリアージして、リリース ブロッカーの commit をバックポートします。
    • バックポートできるのは、メインブランチでの下位互換性のある commit のみです。 マージの競合を解決するための軽微な変更は許容されます。
  4. Bazel の管理者向けに、Cherry-Pick Request Issue を使用して変更をバックポートしました。

    • Bazel の管理者は、特定の commit のチェリーピックをリクエストできる リリースブランチにルーティングしますこのプロセスを開始するには 確認してみましょう。次にその方法をご紹介します。

      1. チェリーピックのリクエストを開きます。
      2. リクエストの詳細を入力する <ph type="x-smartling-placeholder">
          </ph>
        • タイトル: リクエストの簡潔でわかりやすいタイトルを指定します。
        • commit ID: 目的の commit の ID を入力します。 選択します。複数の commit がある場合は、 カンマで区切ります。
        • カテゴリ: リクエストのカテゴリを指定します。
        • レビュアー: レビュアーが複数いる場合は、それぞれの GitHub を分離します。 カンマで区切って入力してください
      3. マイルストーンを設定する <ph type="x-smartling-placeholder">
          </ph>
        • [マイルストーン] を見つけます。設定をクリックします。
        • 適切な X.Y.Z リリース ブロッカーを選択します。この操作 リクエストを処理するチェリーピック bot がトリガーされる 「release-X.Y.Z」のされます。
      4. 問題を報告する <ph type="x-smartling-placeholder">
          </ph>
        • 詳細をすべて入力して目標を設定したら 問題を送信します。
    • チェリーピック bot がリクエストを処理し、 そのコミットがチェリーピッキングの対象となるかどうか。条件 commit は選択可能です。つまり、コミット契約が commit を選択しながらマージの競合が発生すると、 bot が新しい pull リクエストを作成します。pull レイヤが Bazel チームのメンバーによって承認された場合、 commit が選択され、リリース ブランチにマージされます。 完成したチェリーピックリクエストの視覚的な例は 詳しくは、 をタップします。

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

  6. すべての既知の時点でリリース ブランチから新しいリリース候補版を作成する 解消されます

    • リリース候補版の発表日は bazel-discuss、 Bazel チームは、候補のコミュニティ バグレポートをモニタリングします。
    • 新たなリリース ブロッカーを特定した場合は、最後のステップに戻って すべての問題を解決した後に新しいリリース候補を作成する。
    • リリース ブランチに新機能を追加することは、 最初のリリース候補版が作成されます。選択できるのは重要な あります。選択が必要な場合は、 「今回の変更が重要な理由」と どうすればよいでしょうか。この変化によって どうすればよいでしょうか。
  7. これ以上リリースされない場合は、リリース候補版を公式リリースとしてプッシュします。 阻害要因が見つかる

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

回帰を報告する

新しい Bazel リリース、リリース候補版、さらにはリリース候補版で回帰が見つかった場合 Bazel を HEAD で、バグを報告してください。 GitHub。次を使用: Bazelisk が犯人 commit を二分割し、この情報をバグに含める レポート

たとえば、ビルドが Bazel 6.1.0 で成功し、2 番目の 1 つで失敗した場合です。 バージョン 6.2.0 では、

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

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

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

ルールの互換性

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