リリース ポリシー

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

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

リリース候補

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

リリース候補については、bazel-discuss でご案内しています。数日間にわたって、Bazel チームがコミュニティ バグレポートをモニタリングして、志願者からの回帰がないかどうかを調べます。

リリース

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

新機能は、カットされた後はリリース候補として選択されません。 また、新機能がバグが多い場合は、リリース候補からロールバックされる場合があります。リリース候補には、リリース後に影響が及ぶ可能性や互換性を破る可能性のあるバグのみが修正されます。

リリースが翌日となるのは、翌日の営業日のみです。

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

テスト

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

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