[9.1.0] Bzlmod: Make compatibility_level and max_compatibility_level noops#28616
[9.1.0] Bzlmod: Make compatibility_level and max_compatibility_level noops#28616iancha1992 merged 1 commit intorelease-9.1.0from
Conversation
…noops Increasing `compatibility_level` leads to version conflicts that are difficult for end users to resolve. Therefore, we are making `compatibility_level` and `max_compatibility_level` no-ops. This will be effective from Bazel 8.6.0 and 9.1.0. Module maintainers introducing major breaking changes should ensure that build failures provide clear error messages and actionable migration paths. Fixes #22972 RELNOTES: The `compatibility_level` and `max_compatibility_level` attributes of `module` in MODULE.bazel are now no-ops. Module maintainers should stop specifying those attributes and provide clear build time error messages and actionable migration paths when making major breaking changes. Closes #28600. PiperOrigin-RevId: 868151978 Change-Id: I217e7f0c02e729f7c89ebab140d8bbd754db13be
github-actions
Bot
added
team-ExternalDeps
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request effectively makes the compatibility_level and max_compatibility_level attributes in Bzlmod no-ops. The changes include updating documentation to reflect this deprecation, modifying the implementation to ignore these attributes, and adding warnings to guide users toward removing them from their MODULE.bazel files. The implementation is solid, but I've identified an improvement opportunity to broaden the scope of the new deprecation warnings.
| if (compatibilityLevel.toInt("compatibility_level") != -1 | ||
| && context.getModuleBuilder().getKey().equals(ModuleKey.ROOT)) { |
There was a problem hiding this comment.
The warning for using the deprecated compatibility_level attribute is only issued for the root module. This check is too restrictive, as it won't warn users who are using a non-registry override (e.g., local_path_override) and have specified this attribute in the overridden module's MODULE.bazel file. Since developers can edit these files, they should also be warned about the deprecation.
A similar issue exists for the max_compatibility_level warning on lines 291-292.
To address this, you could consider passing information about whether a module is from a non-registry override into the ModuleThreadContext and using that in this condition.
github-actions
Bot
removed
the
awaiting-review
3 participants
Increasing
compatibility_levelleads to version conflicts that are difficult for end users to resolve. Therefore, we are makingcompatibility_levelandmax_compatibility_levelno-ops. This will be effective from Bazel 8.6.0 and 9.1.0.Module maintainers introducing major breaking changes should ensure that build failures provide clear error messages and actionable migration paths.
Fixes #22972
RELNOTES: The
compatibility_levelandmax_compatibility_levelattributes ofmodulein MODULE.bazel are now no-ops. Module maintainers should stop specifying those attributes and provide clear build time error messages and actionable migration paths when making major breaking changes.Closes #28600.
PiperOrigin-RevId: 868151978
Change-Id: I217e7f0c02e729f7c89ebab140d8bbd754db13be