このページでは、下位互換性を処理する方法について説明します。これには、あるリリースから別のリリースへの移行や、互換性のない変更を通知する方法が含まれます。
Bazel は進化しています。LTS メジャー バージョンの一部としてリリースされるマイナー バージョンは、完全に下位互換性があります。LTS メジャー リリース間の変更には、移行作業が必要な互換性のない変更が含まれている場合があります。Bazel リリースの頻度の仕組み について詳しくは、 Bazel の長期サポート（LTS）リリースの発表をご覧ください。
概要
- 互換性を破る変更には
--incompatible_*フラグを使用することをおすすめします。 --incompatible_*フラグごとに、GitHub の問題で動作の変更について説明し、移行レシピを提供することを目指しています。--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 の問題 "incompatible-change" ラベルが付いたものです。
互換性のない変更ごとに、問題には次の情報が記載されます。
- 互換性のない変更を制御するフラグの名前
- 変更された機能の説明
- 移行レシピ
互換性のない変更が Bazel at HEAD（したがって、次の Bazel ローリング リリース）で移行できるようになったら、migration-ready ラベルを付けます。互換性のないフラグが HEAD で切り替えられると、互換性のない変更の問題はクローズされます。