Allow overriding root module version on command line

[SanjayVas]

Description of the feature request:

Allow overriding the root module version specified in MODULE.bazel from the bazel command line.

Which category does this issue belong to?

Configurability

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

Currently, the only way to specify the root module version is in the MODULE.bazel file. The root module version is generally not known until a release event, which usually does not involve the ability to change code. Indeed, the common practice for Bazel registries is to include a patch to MODULE.bazel that sets the module version.

Allowing the module version to be overridden using a command line option would allow CI/CD systems to specify the version as part of the release process. Combined with the native.module_version() function (see #17114), this can be used to plumb the module version to rules/macros for tagging release artifacts.

This is somewhat related to ctx.version_file and stamping, but that mechanism does not really work for versioned modules.

Concrete use case: Maven artifacts

Assume a project consisting of multiple Bazel modules, each of which depends on and publishes Maven artifacts using rules_jvm_external. Library targets (e.g. java_library) need to be tagged with Maven coordinates, which include the version. When a root module depends on a library from another module, the Maven artifact version should match the module version. This can be accomplished using native.module_version() as described above.

The common pattern for Maven projects is to have the development version be "\<future version>-SNAPSHOT". For example, if you're developing with the intent to release version 3.2.0 then your artifact version during development may be 3.2.0-SNAPSHOT. During the release process, this is replaced with the actual release version. Note that this may not be just dropping the -SNAPSHOT suffix. For example, if it turns out there's a bug fix that needs to go out as 3.1.1 instead.

With this feature, the version in the MODULE.bazel file could be 3.2.0-SNAPSHOT and the CI/CD system can override this with the actual release version during the release process.

Which operating system are you running Bazel on?

Linux

What is the output of bazel info release?

release 7.0.1

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 ?

N/A

Have you found anything relevant by searching the web?

No response

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

No response

[fmeum]

Maybe not as convenient as a flag, but you could use something like buildozer 'set version 1.2.3' //MODULE.bazel:%module to update the MODULE.bazel file in CI.

[SanjayVas]

@fmeum Thanks, that's certainly helpful for the short term. The main reason it's not a true workaround is that CI should usually have --lockfile_mode=error set. Changing the contents of MODULE.bazel also means handling lockfile checks.

[Wyverald]

@fmeum Thanks, that's certainly helpful for the short term. The main reason it's not a true workaround is that CI should usually have --lockfile_mode=error set. Changing the contents of MODULE.bazel also means handling lockfile checks.

With Bazel 7.2.0+, changing the root module version (which doesn't affect module version resolution at all) will no longer interfere with --lockfile_mode=error.

[SanjayVas]

With Bazel 7.2.0+, changing the root module version (which doesn't affect module version resolution at all) will no longer interfere with --lockfile_mode=error.

I just tested this after upgrading to Bazel 7.2.1 and still got an error with --lockfile_mode=error. Running bazel mod deps --lockfile_mode=update updates the usagesDigest field for two module extensions: @@rules_jvm_external~//:extensions.bzl%maven and @@rules_oci~//oci:extensions.bzl%oci.

[fmeum]

You are right, this makes sense: module extensions see the version as declared by any module with a use_extension for them. Since extensions can perform arbitrary logic based on it, there is no way to change the version without invalidating the lockfile to some extent. Having a flag for it unfortunately wouldn't change this.