下位互換性

問題を報告する ソースを表示

このページでは、あるリリースから別のリリースに移行することや、互換性のない変更を伝える方法など、下位互換性の処理方法について説明します。

Bazel は進化しています。LTS メジャー バージョンの一部としてリリースされたマイナー バージョンには、完全な下位互換性があります。新しいメジャー LTS リリースでは、移行作業が必要な互換性のない変更が行われる場合があります。Bazel のリリースモデルの詳細については、リリースモデルのページをご覧ください。

まとめ

  1. 互換性を破る変更には --incompatible_* フラグを使用することをおすすめします。
  2. GitHub の問題では、--incompatible_* フラグごとに動作変更について説明し、移行レシピの提供を目指しています。
  3. 互換性のないフラグは、デフォルトで有効にせずに最新の LTS リリースにバックポートすることをおすすめします。
  4. --experimental_* フラグで保護される API と動作は、随時変更される可能性があります。
  5. --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（次の Bazel ローリング リリース）で移行できる状態になったら、migration-ready ラベルを付けます。互換性のないフラグを HEAD で反転すると、互換性のない変更の問題がクローズされます。