リリース ポリシー

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。
問題を報告する ソースを表示

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 を使用する重要なプロジェクトがある場合は、現在のリリース候補を追跡する自動テストプロセスを確立し、回帰があれば報告することをおすすめします。