このページでは、あるリリースから別のリリースへの移行や、互換性のない変更を伝える方法など、下位互換性の処理方法について説明します。
Bazel は進化を続けています。LTS メジャー バージョンの一部としてリリースされたマイナー バージョンには、完全な下位互換性があります。新しいメジャー LTS リリースには、移行作業を必要とする互換性のない変更が含まれている場合があります。Bazel のリリースモデルの詳細については、リリースモデルのページをご覧ください。
まとめ
- 互換性を破る変更には、
--incompatible_*フラグを使用することをおすすめします。 - GitHub の問題は、
--incompatible_*フラグごとに動作の変化を説明し、移行レシピを提供することを目的としています。 - 互換性のないフラグは、デフォルトでフラグを有効にせずに、最新の LTS リリースにバックポートすることが推奨されます。
--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 の問題が必要です。
互換性のないフラグと関連する変更は、デフォルトでフラグを有効にせずに、最新の LTS リリースにバックポートすることが推奨されます。これにより、次の LTS リリースが利用可能になる前に、ユーザーは互換性のない変更のために移行できます。
互換性のない変更の伝達
互換性のない変更に関する主な情報源は、「互換性のない変更」ラベルでマークされた GitHub の問題です。
互換性のない変更が行われるたびに、問題により次のことが明らかになります。
- 互換性のない変更を制御するフラグの名前
- 変更された機能の説明
- 移行レシピ
互換性のない変更が Bazel で HEAD で（つまり、次の Bazel ローリング リリースで）移行できる状態になったら、migration-ready ラベルでマークする必要があります。互換性のない変更の問題は、互換性のないフラグが HEAD で反転されるとクローズされます。