Skip to content

Bzlmod: Make compatibility_level and max_compatibility_level noops#28600

Closed
meteorcloudy wants to merge 3 commits intobazelbuild:masterfrom
meteorcloudy:noop_compatibility_evel
Closed

Bzlmod: Make compatibility_level and max_compatibility_level noops#28600
meteorcloudy wants to merge 3 commits intobazelbuild:masterfrom
meteorcloudy:noop_compatibility_evel

Conversation

@meteorcloudy
Copy link
Copy Markdown
Member

@meteorcloudy meteorcloudy commented Feb 10, 2026 •
edited
Loading

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.

@meteorcloudy meteorcloudy mentioned this pull request Feb 10, 2026
Closed
@meteorcloudy
Copy link
Copy Markdown
Member Author

meteorcloudy commented Feb 10, 2026

@bazel-io fork 9.1.0

@meteorcloudy
Copy link
Copy Markdown
Member Author

meteorcloudy commented Feb 10, 2026

@bazel-io fork 8.6.0

@bazel-io bazel-io mentioned this pull request Feb 10, 2026
Closed
@meteorcloudy meteorcloudy marked this pull request as ready for review February 10, 2026 10:32
@bazel-io bazel-io mentioned this pull request Feb 10, 2026
Closed
@github-actions github-actions Bot added team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. team-Documentation Documentation improvements that cannot be directly linked to other team labels awaiting-review PR is awaiting review from an assigned reviewer labels Feb 10, 2026
gemini-code-assist[bot]
gemini-code-assist Bot reviewed Feb 10, 2026
View reviewed changes
Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request effectively makes compatibility_level and max_compatibility_level no-ops by ignoring their values and removing related logic. The documentation has been updated accordingly, and warnings are now issued when these deprecated attributes are used.

My main feedback is that the new deprecation warnings are currently limited to the root module. This should be expanded to all modules to ensure all maintainers are aware of the change. I've left specific comments with suggestions on how to address this.

Comment thread src/main/java/com/google/devtools/build/lib/bazel/bzlmod/ModuleFileGlobals.java
Comment thread src/main/java/com/google/devtools/build/lib/bazel/bzlmod/ModuleFileGlobals.java
@github-actions github-actions Bot removed the awaiting-review PR is awaiting review from an assigned reviewer label Feb 10, 2026
Wyverald pushed a commit that referenced this pull request Feb 10, 2026
@meteorcloudy @Wyverald
[8.6.0] Bzlmod: Make compatibility_level and max_compatibility_level …
bdab937 
…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
@Wyverald Wyverald mentioned this pull request Feb 10, 2026
Merged
Wyverald pushed a commit that referenced this pull request Feb 10, 2026
@meteorcloudy @Wyverald
[9.1.0] Bzlmod: Make compatibility_level and max_compatibility_level …
9a938ef 
…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
@Wyverald Wyverald mentioned this pull request Feb 10, 2026
Merged
github-merge-queue Bot pushed a commit that referenced this pull request Feb 10, 2026
@Wyverald @meteorcloudy
[8.6.0] Bzlmod: Make compatibility_level and max_compatibility_level …
cb14316 
…noops (#28615)

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

Co-authored-by: Yun Peng <[email protected]>
github-merge-queue Bot pushed a commit that referenced this pull request Feb 10, 2026
@Wyverald @meteorcloudy
[9.1.0] Bzlmod: Make compatibility_level and max_compatibility_level …
f46dfcb 
…noops (#28616)

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

Co-authored-by: Yun Peng <[email protected]>
mbland added a commit to mbland/rules_scala that referenced this pull request Feb 27, 2026
@mbland
Bump dependency versions, drop compatibility_level
7c8c969 
Removes `compatibility_level` from the `module` directive in
`MODULE.bazel`. Bumps the following dependency versions:

Bazel modules:
- `bazel_features`: 1.38.0 => 1.42.0
- `bazel_skylib`: 1.8.2 => 1.9.0
- `protobuf`: v33.4 => v33.5
- `rules_cc`: 0.2.14 => 0.2.17
- `rules_go`: 0.59.0 => 0.60.0
- `rules_java`: 9.3.0 => 9.6.1
- `rules_python`: 1.7.0 => 1.8.5

Golang:
- Golang: 1.25.5 => 1.26.0
- `golang.org/x/tools`: v0.40.0 => v0.42.2

Maven artifacts:
- `org.scalameta:scalafmt-core_*`: 3.10.2 => 3.10.7
- `org.scala-sbt:compiler-interface`: 1.11.0 => 1.12.0
- `org.scala-sbt:util-interface`: 1.11.7 => 1.12.4
- `org.google.protobuf:protobuf-java`: 4.33.4 => 4.33.5
- `io.grpc:grpc-*`: 1.77.0 => 1.79.0
- `com.google.api.grpc:proto-google-common-protos`: 2.63.1 => 2.66.0

---

Most of the change is a routine dependency version bump before a new
patch level release. There are two specific changes of note.

First, Bazel 8.6.0 and 9.1.0 effectively make the `compatibility_level`
attribute of the `module` directive a no-op per bazelbuild/bazel#28600.

Second, though `protobuf` v34.0 is out, we only update to v35.5 because
v40.0 drops support for Bazel 7 (in maintenance mode until December
2026):

- https://github.com/protocolbuffers/protobuf/releases/tag/v34.0
- protocolbuffers/protobuf@304c9ba
- https://protobuf.dev/support/migration/#dropped-bazel-7-support
- https://bazel.build/release

I'll confer with the Bazel Rules Author SIG on 2026-03-03 regarding
whether or not we should begin planning to deprecate Bazel 7 support.
Doing so would likely necessitate a major version bump to `rules_scala`
8.0.0. (It would be good to get some other large pending changes in
before then, notably the possible `rules_jvm_external` migration.)
@mbland mbland mentioned this pull request Feb 27, 2026
Merged
mbland added a commit to bazel-contrib/rules_scala that referenced this pull request Feb 27, 2026
@mbland
Bump dependency versions, drop compatibility_level (#1815)
8cef613 
Removes `compatibility_level` from the `module` directive in
`MODULE.bazel`. Bumps the following dependency versions:

Bazel modules:
- `bazel_features`: 1.38.0 => 1.42.0
- `bazel_skylib`: 1.8.2 => 1.9.0
- `protobuf`: v33.4 => v33.5
- `rules_cc`: 0.2.14 => 0.2.17
- `rules_go`: 0.59.0 => 0.60.0
- `rules_java`: 9.3.0 => 9.6.1
- `rules_python`: 1.7.0 => 1.8.5

Golang:
- Golang: 1.25.5 => 1.26.0
- `golang.org/x/tools`: v0.40.0 => v0.42.2

Maven artifacts:
- `org.scalameta:scalafmt-core_*`: 3.10.2 => 3.10.7
- `org.scala-sbt:compiler-interface`: 1.11.0 => 1.12.0
- `org.scala-sbt:util-interface`: 1.11.7 => 1.12.4
- `org.google.protobuf:protobuf-java`: 4.33.4 => 4.33.5
- `io.grpc:grpc-*`: 1.77.0 => 1.79.0
- `com.google.api.grpc:proto-google-common-protos`: 2.63.1 => 2.66.0

---

Most of the change is a routine dependency version bump before a new
patch level release. There are two specific changes of note.

First, Bazel 8.6.0 and 9.1.0 effectively make the `compatibility_level`
attribute of the `module` directive a no-op per bazelbuild/bazel#28600.

Second, though `protobuf` v34.0 is out, we only update to v35.5 because
v40.0 drops support for Bazel 7 (in maintenance mode until December
2026):

- https://github.com/protocolbuffers/protobuf/releases/tag/v34.0
- protocolbuffers/protobuf@304c9ba
- https://protobuf.dev/support/migration/#dropped-bazel-7-support
- https://bazel.build/release

I'll confer with the Bazel Rules Author SIG on 2026-03-03 regarding
whether or not we should begin planning to deprecate Bazel 7 support.
Doing so would likely necessitate a major version bump to `rules_scala`
8.0.0. (It would be good to get some other large pending changes in
before then, notably the possible `rules_jvm_external` migration.)
@mbland mbland mentioned this pull request Feb 27, 2026
Closed
@jwnimmer-tri jwnimmer-tri mentioned this pull request Apr 17, 2026
Open
@albertocavalcante albertocavalcante mentioned this pull request Apr 30, 2026
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@Wyverald Wyverald Awaiting requested review from Wyverald Wyverald is a code owner

1 more reviewer

@gemini-code-assist gemini-code-assist[bot] gemini-code-assist[bot] left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

team-Documentation Documentation improvements that cannot be directly linked to other team labels team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Misreported error with max_compatibility_level violation

1 participant

@meteorcloudy