Bazel Version Constraints in BCR

[shantanu-gontia]

Hi, I was looking into adding LLVM18 to the BCR. I noticed there's already an entry for llvm-project 17.0.3, so I tried getting it to work. But apparently, it doesn't work with Bazel Versions >= 7.0 (I think this is because exec_tools no longer works in genrules).

But there was no way to know this from the BCR entry. Is it possible/worthwhile to let us know which Bazel versions a module is supported on. Or, even to complain that the module might not work with your version of Bazel.

[keith]

Theoretically folks should be annotating their MODULE.bazel with this compatibility:

bazel-central-registry/modules/rules_apple/3.1.0/MODULE.bazel

Line 4 in e5914f4

bazel_compatibility = [">=6.0.0"],

In which case you would be able to see it there. And it would fail earlier than some random bazel API change. I think thus far folks have been pretty lax on that, and it doesn't help you spot the case when a transitive dependency does encode this requirement and it hits you too. I would expect this to improve as more folks use bzlmod

[shantanu-gontia]

That's great. Exactly what I was looking for. Moving forward, can (should?) this be enforced for new Modules?

[fmeum]

We could require a bazel_compatibility argument if a module doesn't list Bazel 6 in its presubmit.yml. but we can't modify module files after release, so incompatibilities with future bazel versions are hard to track.

@meteorcloudy

[meteorcloudy]

I think that requirement makes sense. But "Bazel 6" should be "the last maintained major release that officially supports Bzlmod" (https://bazel.build/release#support-matrix) since we probably don't want to require testing against a deprecated Bazel version.