このページでは、リリース間の移行や互換性のない変更の通知など、下位互換性を処理する方法について説明します。
Bazel は進化しています。LTS メジャー バージョンの一部としてリリースされたマイナー バージョンは、完全に下位互換性があります。LTS のメジャー リリース間の変更には、互換性のない変更が含まれ、移行作業が必要になる場合があります。Bazel のリリース頻度の仕組みについて詳しくは、Bazel の長期サポート（LTS）リリースの発表をご覧ください。
概要
- 破壊的変更には
--incompatible_*フラグを使用することをおすすめします。 --incompatible_*フラグごとに、GitHub の問題で動作の変更が説明され、移行手順が提供されます。--experimental_*フラグで保護されている API と動作は、いつでも変更される可能性があります。--experimental_*フラグまたは--incompatible_*フラグを使用して本番環境ビルドを実行しないでください。
このポリシーに準拠する方法
安定した機能とは
一般に、--experimental_... フラグのない API または動作は、Bazel で安定したサポートされている機能と見なされます。
以下が該当します。
- Starlark 言語と API
- Bazel にバンドルされているルール
- Bazel API（Remote Execution API や Build Event Protocol など）
- フラグとそのセマンティクス
互換性のない変更と移行レシピ
新しいリリースで互換性のない変更がある場合は、Bazel チームがコード（BUILD ファイルと .bzl ファイル、スクリプト内の Bazel の使用、Bazel API の使用など）の更新に役立つ移行レシピを提供することを目標としています。
互換性のない変更には、--incompatible_* フラグと対応する GitHub の問題が関連付けられている必要があります。
互換性のない変更の通知
互換性のない変更に関する主な情報源は、「incompatible-change」ラベルが付いた GitHub の問題です。
互換性のない変更ごとに、問題には次の情報が表示されます。
- 互換性のない変更を制御するフラグの名前
- 変更された機能の説明
- 移行レシピ
互換性のない変更が HEAD の Bazel で移行の準備が整っている場合（つまり、次の Bazel ローリング リリースでも移行の準備が整っている場合）、migration-ready ラベルを付ける必要があります。互換性のない変更の問題は、HEAD で互換性のないフラグが反転されるとクローズされます。