このページでは、下位互換性に対処する方法について説明します。 リリース間の移行や、コミュニケーション方法についても おすすめします。
Bazel は進化しています。LTS メジャーの一部としてリリースされたマイナー バージョン バージョンには完全な下位互換性があります。新しいメジャー LTS 移行作業を必要とする互換性のない変更がリリースに含まれる場合があります。 Bazel のリリースモデルについて詳しくは、リリース モデルのページを参照してください。
概要
- 互換性を破る変更には、
--incompatible_*フラグを使用することをおすすめします。 --incompatible_*フラグごとに、GitHub の問題で 移行レシピを提供することを目的としています。- 互換性のないフラグは、デフォルトでフラグを有効にせずに、最新の 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 の問題 「互換性のない変更」とマークされる label に移動できます。
互換性のない変更ごとに、問題には次の情報が表示されます。
- 互換性のない変更を制御するフラグの名前
- 変更された機能の説明
- 移行レシピ
互換性のない変更が HEAD の Bazel で移行の準備が整っている場合（つまり、次の Bazel ローリング リリースでも移行の準備が整っている場合）、migration-ready ラベルを付ける必要があります。互換性のない変更の問題は、HEAD で互換性のないフラグが反転するとクローズされます。