リリースモデル

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

サポート マトリックス

すべての Bazel LTS リリースは、GitHub の リリース ページで確認できます。

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

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

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

また、リリース前のバージョンは、次のメジャー バージョン番号にハイフンと 日付の接尾辞を追加して示されます。

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

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

4. Bazel メンテナー向けの Cherry-Pick Request Issue を使用して変更をバックポートします。

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

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

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

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

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

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

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

7. リリース ブロッカーが他にない場合は、リリース候補を公式リリースとして push します。

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

回帰を報告する

ユーザーが新しい Bazel リリース、リリース候補、または HEAD の Bazel で回帰を見つけた場合は、 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 の二分検索機能に関するドキュメントをご覧ください。

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

ルールの互換性

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