リリース ポリシー

Bazel は、長期サポート(LTS)リリースモデルを維持しています。このモデルでは、メジャー バージョンは 9 か月ごとにリリースされ、マイナー バージョンは毎月リリースされます。このページでは、Bazel のリリース ポリシー(リリース候補、タイムライン、お知らせ、テストなど)について説明します。

Bazel のリリースは GitHub で入手できます。

リリース候補

通常、Bazel の新しいバージョンのリリース候補は毎月初めに作成されます。作業は、リリース予定日を示す GitHub のリリースバグによって追跡され、現在のリリース マネージャーに割り当てられます。リリース候補は、すべての Bazel 単体テストに合格し、Buildkite でテストされたプロジェクトで不要なリグレッションが発生していない必要があります。

リリース候補は bazel-discuss で発表されます。今後数日間、Bazel チームはコミュニティ バグレポートをモニタリングし、候補に回帰がないか確認します。

リリース

回帰が検出されない場合、1 週間後に候補が正式にリリースされます。ただし、回帰によってリリース候補のリリースが遅れる可能性があります。回帰が見つかった場合、Bazel チームは、対応する選り方をリリース候補に適用して修正します。最初のリリース候補から 1 週間後に連続する 2 営業日で回帰が見つからなかった場合、その候補はリリースされます。

カットされた新機能がリリース候補として選択されることはありません。さらに、新しい機能にバグがある場合、その機能がリリース候補からロールバックされる場合があります。カット後にリリース候補で修正されるのは、リリースビルドに大きな影響を与える可能性があるバグのみです。

リリースは翌営業日にのみリリースされます。

最新リリースで重大な問題が見つかった場合、Bazel チームはリリースに修正を適用してパッチリリースを作成します。このパッチは、新しいリリースを作成するのではなく既存のリリースを更新するため、パッチリリース候補は 2 営業日後にリリースされます。

テスト

ヘッドにビルドされた Bazel バイナリとリリース バイナリを使用して、ci.bazel.build で実行されているすべてのプロジェクトのナイトリー ビルドが実行されます。互換性を破る変更の影響を受けるプロジェクトには 通知されます

リリース候補版が発行されると、リリース候補版バイナリを使用して、TensorFlow などの他の Google プロジェクトが完全なテストスイートでテストされます。Bazel を使用する重要なプロジェクトがある場合は、現在のリリース候補を追跡し、回帰を報告する自動テストプロセスを確立することをおすすめします。