このページでは、下位互換性の処理方法について説明します。これには、リリース間の移行や、互換性のない変更を伝える方法が含まれます。
Bazel は進化しています。LTS メジャー バージョンの一部としてリリースされたマイナー バージョンには、完全な下位互換性があります。新しいメジャー LTS リリースには、移行作業が必要となる互換性のない変更が含まれている場合があります。Bazel のリリースモデルの詳細については、リリースモデルのページをご覧ください。
概要
- 破壊的変更には
--incompatible_*フラグを使用することをおすすめします。 --incompatible_*フラグごとに、GitHub の問題で動作の変更が説明され、移行レシピの提供が目指されています。- 互換性のないフラグは、デフォルトでフラグを有効にせずに、最新の LTS リリースにバックポートすることが推奨されます。
--experimental_*フラグで保護された API と動作は、いつでも変更される可能性があります。--experimental_*フラグまたは--incompatible_*フラグを指定して本番環境ビルドを実行しないでください。
このポリシーを遵守する方法
- Bazel ユーザー向け - Bazel を更新する方法
- コントリビューター向け - 互換性のない変更に関するベスト プラクティス
- リリース マネージャー向け - 問題のラベルとリリースを更新する方法
安定版の機能とは
一般に、--experimental_... フラグのない API または動作は、Bazel の安定したサポート対象の機能と見なされます。
これには以下が該当します。
- Starlark 言語と API
- Bazel にバンドルされているルール
- リモート実行 API やビルド イベント プロトコルなどの Bazel API
- フラグとそのセマンティクス
互換性のない変更と移行レシピ
新しいリリースで互換性のない変更があるたびに、Bazel チームは、コード（BUILD ファイルと .bzl ファイル、スクリプトでの Bazel の使用、Bazel API の使用など）の更新に役立つ移行レシピを提供することを目指しています。
互換性のない変更には、関連する --incompatible_* フラグと対応する GitHub の問題が必要です。
互換性のないフラグと関連する変更は、デフォルトでフラグを有効にせずに、最新の LTS リリースにバックポートすることをおすすめします。これにより、ユーザーは次の LTS リリースが利用可能になる前に、互換性のない変更を移行できます。
互換性のない変更を通知する
互換性のない変更に関する情報の主なソースは、「incompatible-change」ラベルが付いた GitHub の問題です。
互換性のない変更ごとに、問題には次の内容が指定されます。
- 互換性のない変更を制御するフラグの名前
- 変更された機能の説明
- 移行レシピ
互換性のない変更が Bazel HEAD での移行の準備ができたら（次の Bazel ローリング リリースでも同様）、migration-ready ラベルを付けてマークする必要があります。互換性のない変更の問題は、HEAD で互換性のないフラグが反転されるとクローズされます。