Bazel Starlark ルールは、次の 2 つのシナリオで Bazel LTS リリースとの互換性を損なう可能性があります。
- ルールが依存する機能が HEAD の Bazel から削除されるため、今後の LTS リリースとの互換性が損なわれる。
- ルールが依存する機能が新しい Bazel LTS リリースでのみ使用できるため、現在の LTS リリースまたは古い LTS リリースとの互換性が損なわれる。
一方、ルール自体も、ユーザーにとって互換性のない変更をリリースする可能性があります。Bazel の互換性を破る変更と組み合わせると、ルール バージョンと Bazel バージョンのアップグレードは、Bazel ユーザーにとってストレスの原因となることがよくあります。このページでは、ルール作成者が Bazel とのルールの互換性を維持して、ユーザーが Bazel とルールを簡単にアップグレードできるようにする方法について説明します。
管理可能な移行プロセス
Bazel のすべてのバージョンとルールのすべてのバージョンとの互換性を保証することは明らかに不可能ですが、移行プロセスを Bazel ユーザーにとって管理しやすいものにすることを目指しています。管理可能な移行 プロセスとは、ユーザーがルールのメジャー バージョンと Bazel のメジャー バージョンを同時にアップグレードする必要がないプロセスを指します。これにより、ユーザーは 1 つのソースからの互換性のない変更を一度に処理できます。
たとえば、次のような互換性マトリックスの場合:
- rules_foo 1.x + Bazel 4.x から rules_foo 2.x + Bazel 5.x への移行は、ユーザーが rules_foo と Bazel のメジャー バージョンを同時にアップグレードする必要があるため、管理可能とは言えません。
- rules_foo 2.x + Bazel 5.x から rules_foo 3.x + Bazel 6.x への移行は、ユーザーが Bazel のメジャー バージョンを変更せずに rules_foo を 2.x から 3.x にアップグレードしてから、Bazel を 5.x から 6.x にアップグレードできるため、管理可能と見なされます。
| rules_foo 1.x | rules_foo 2.x | rules_foo 3.x | HEAD | |
|---|---|---|---|---|
| Bazel 4.x | ✅ | ❌ | ❌ | ❌ |
| Bazel 5.x | ❌ | ✅ | ✅ | ❌ |
| Bazel 6.x | ❌ | ❌ | ✅ | ✅ |
| HEAD | ❌ | ❌ | ❌ | ✅ |
❌: メジャー ルール バージョンのどのバージョンも Bazel LTS リリースと互換性がありません。
✅: ルールの少なくとも 1 つのバージョンが、Bazel LTS リリースの最新バージョンと互換性があります。
ベスト プラクティス
Bazel ルールの作成者は、次のベスト プラクティスに従うことで、ユーザーにとって管理しやすい移行プロセスを確保できます。
- ルールはセマンティック バージョニングに従う必要があります。つまり、同じ メジャー バージョンのマイナー バージョンには下位互換性があります。
- HEAD のルールは、最新の Bazel LTS リリースと互換性がある必要があります。
- HEAD のルールは、HEAD の Bazel と互換性がある必要があります。これを実現するには、次の方法があります。
- ルールの最新のメジャー バージョンは、最新の Bazel LTS リリースと互換性がある必要があります。
- ルールの新しいメジャー バージョンは、ルールの前のメジャー バージョンでサポートされている最後の Bazel LTS リリースと互換性がある必要があります。
2 と 3 を実現することが最も重要なタスクです。これにより、4 と 5 を実現できます。自然に。
HEAD の Bazel と最新の Bazel LTS リリースの両方との互換性を維持しやすくするために、ルール作成者は次のことを行えます。
- 下位互換性のある機能を最新の LTS リリースにバックポートするようリクエストします。詳細については、リリース プロセス をご覧ください。
- bazel_features を使用して Bazel の機能を検出します。
一般に、推奨されるアプローチを使用すると、ルールは Bazel の互換性のない変更を移行し、最新の Bazel LTS リリースとの互換性を維持しながら、HEAD で新しい Bazel 機能を利用できるようになります。