このページでは、下位互換性を確保する方法と、 リリース間の移行や、コミュニケーション方法についても おすすめします。
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 の問題 「互換性のない変更」とマークされるlabel に移動できます。
互換性のない変更が行われるたびに、問題により次のことが明らかになります。
- 互換性のない変更を制御するフラグの名前
- 変更された機能の説明
- 移行レシピ
互換性のない変更が Bazel で（つまり、次の Bazel ローリング リリースで）移行できる状態になったら、migration-ready ラベルでマークする必要があります。互換性のない変更の問題は、互換性のないフラグが HEAD で反転されるとクローズされます。