Bzlmod version could have better support for asking for a min/max range

[esrauchg]

Description of the feature request:

In cases like Protobuf-C++ and absl-cpp:

• Both projects are under active development and both make occasional small breaking changes, which have rolling deprecation windows
• Both don't really want two versions installed at a given time (generally can result in ODR violations when two versions are linked)

The status quo is that both projects just set module(compatibility_version=1) and don't change it; the current compatibility_version semantic doesn't really line up with this usecase because:

• Because bazel uses the "maximum declared minimum-required version", the only thing bumping compatbility_version can really do is induce Bazel to want to install 2 versions, which would typically just be a breakage anyway

• Most of the breaking changes actually only affect a small portion of users, so eg most people on protobuf-23 can use protobuf-29 even though there has officially been breaking changes in between (eg, removal or renaming of obscure and rarely used apis is a breaking change that actually breaks almost no one in practice)

• The rolling compatibility window behavior means that the version compat numbers aren't really so 'clean', eg protobuf released in 2023 may realistically be compatible with absl from 2022-2024, protobuf released in 2022 may realistically be compatible with absl from 2021-2023.

The status quo ends up that protobuf and absl just declare compatibility_version=1 and never bump it. This has other undesirable behavior though where eg a binary uses:

• Library 1 declares that its min version is protobuf-23 + absl-20230101
• Library 2 declares its min version in absl-20240801

In reality the overall build will work with [protobuf-29 + absl-20240801] and maybe even work with [protobuf-23 + absl-20230101] (*this one actively contrary the claimed min version of library2), but bazel will select protobuf-23 + absl-20240801 which are actually incompatible with eachother and the build will not succeed with that combination of versions selected)

One possible way this could work better is if the protobuf module could specify a maximum absl version, and specify one that doesn't even exist at time of release (for example min=absl-20230101 max=absl-20240101). If the version number could be understood as an inequality then it would know that the version is expected to be forward-compatible with versions up to that release number. Then it could see that:

• Library 1 says >= protobuf-23, >= absl-20230101
• Library 2 says >= absl-2040801
• protobuf-23 says [absl >=20220101, absl <= 20240101]
• protobuf-27 says (some higher absl version)

And select protobuf-27 as the minimum version which does satisfies the constraints

Perhaps a similar capability could be work with maximum_compatiblity_version, though it would potentialy need some other adjustments to make it so absl + protobuf reasonably start using compatibility_version() with high versions (including, trying hard to preclude 2 versions being installed).

Which category does this issue belong to?

No response

What underlying problem are you trying to solve with this feature?

Reduce the amount of times that just taking a dep on a few libraries will result in bazel selecting a set of dependencies that are actually incompatible and don't build.

Which operating system are you running Bazel on?

No response

What is the output of bazel info release?

No response

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response