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