リリース ポリシー

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

Bazel のリリースは GitHub で確認できます。

リリース候補版

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

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

リリース

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

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

リリースは、翌日が営業日である日にのみリリースされます。

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

テスト

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

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