Release Notes:

Configurability:
+ aquery: `//foo:bar` now means "all configured targets with label `//foo:bar`" instead of "choose an arbitrary configured target with label `//foo:bar`". This is in line with cquery behavior. (#22135)
+ Added a new flag `--incompatible_disable_native_repo_rules` to disable native repo rule usage in WORKSPACE. All native repo rules now have a Starlark counterpart that can be used in both WORKSPACE and Bzlmod; see #22080 for more details. (#22203)
+ Starlark command-line flags can now be referred to through `alias` targets. (#22212)

ExternalDeps:
+ bzlmod `git_repository` now accepts the `strip_prefix` arg and passes it to the underlying `git_repository` call. (#22137)
+ Added a new `include()` directive to `MODULE.bazel` files, which allows the root module file to be divided into multiple segments. (#22204)
+ Fixed certain deadlocks in repo fetching with worker threads (`--experimental_worker_for_repo_fetching=auto`). (#22261)
+ `print` statements in module files are now only executed for the root module and modules subject to non-registry overrides (e.g. `local_path_override`). (#22263)
+ The new `refresh` value for `--lockfile_mode` behaves like the `update` mode, but additionally forces a refresh of mutable registry content (yanked versions and missing module versions) when switched to or from time to time while enabled. (#22371)
+ `Label` instances passed to `print` or `fail` as positional arguments are now formatted with apparent repository names (optimized for human readability). (#22460)
+ Changes to environment variables read via `getenv` now correctly invalidate module extensions. (#22541)
+ Git merge conflicts in `MODULE.bazel.lock` files can be resolved automatically. See https://bazel.build/external/lockfile#automatic-resolution for the required setup. (#22650)

OSS:
+ Bazel on Linux and BSD now respects the XDG_CACHE_HOME environment variable instead of assuming that ~/.cache/bazel is writable. (#21817)

Performance:
+ Paths in the Linux sandbox are now again identical to those outside the sandbox, even with `--incompatible_sandbox_hermetic_tmp`. (#22407)

Remote-Exec:
+ The combined coverage report produced via `--combined_report=lcov` is now announced on the BES via the new `CoverageReport` event. (#22327)
+ The compact and full execution logs now contain start times for spawns (if available). (#22341)

Rules-CPP:
+ The default Unix C++ toolchain now supports the `parse_headers` feature to validate header files with `--process_headers_in_dependencies`. (#22369)

Starlark-Interpreter:
+ Starlark `min` and `max` buitins now allow a `key` callback, similarly to `sorted`. (#21960)

Acknowledgements:

This release contains contributions from many people at Google, as well as bazel.build machine account, Brentley Jones, Cameron Martin, Daniel Wagner-Hall, Douglas Thor, Fabian Meumertzheim, George Gensure, hvd, Isaac Torres, Keith Smiley, Mark Elliot, oquenchil, Romain Chossart, Son Luong Ngoc, Spencer Putt, Thomas Weischuh, Xdng Yng, Xùdōng Yáng, Zheng Wei Tan.

Release Notes:

Configurability:
+ aquery: `//foo:bar` now means "all configured targets with label `//foo:bar`" instead of "choose an arbitrary configured target with label `//foo:bar`". This is in line with cquery behavior. (#22135)
+ Added a new flag `--incompatible_disable_native_repo_rules` to disable native repo rule usage in WORKSPACE. All native repo rules now have a Starlark counterpart that can be used in both WORKSPACE and Bzlmod; see #22080 for more details. (#22203)
+ Starlark command-line flags can now be referred to through `alias` targets. (#22212)

ExternalDeps:
+ bzlmod `git_repository` now accepts the `strip_prefix` arg and passes it to the underlying `git_repository` call. (#22137)
+ Added a new `include()` directive to `MODULE.bazel` files, which allows the root module file to be divided into multiple segments. (#22204)
+ Fixed certain deadlocks in repo fetching with worker threads (`--experimental_worker_for_repo_fetching=auto`). (#22261)
+ `print` statements in module files are now only executed for the root module and modules subject to non-registry overrides (e.g. `local_path_override`). (#22263)
+ The new `refresh` value for `--lockfile_mode` behaves like the `update` mode, but additionally forces a refresh of mutable registry content (yanked versions and missing module versions) when switched to or from time to time while enabled. (#22371)
+ `Label` instances passed to `print` or `fail` as positional arguments are now formatted with apparent repository names (optimized for human readability). (#22460)
+ Changes to environment variables read via `getenv` now correctly invalidate module extensions. (#22541)
+ Git merge conflicts in `MODULE.bazel.lock` files can be resolved automatically. See https://bazel.build/external/lockfile#automatic-resolution for the required setup. (#22650)

OSS:
+ Bazel on Linux and BSD now respects the XDG_CACHE_HOME environment variable instead of assuming that ~/.cache/bazel is writable. (#21817)

Performance:
+ Paths in the Linux sandbox are now again identical to those outside the sandbox, even with `--incompatible_sandbox_hermetic_tmp`. (#22407)

Remote-Exec:
+ The combined coverage report produced via `--combined_report=lcov` is now announced on the BES via the new `CoverageReport` event. (#22327)
+ The compact and full execution logs now contain start times for spawns (if available). (#22341)

Rules-CPP:
+ The default Unix C++ toolchain now supports the `parse_headers` feature to validate header files with `--process_headers_in_dependencies`. (#22369)

Starlark-Interpreter:
+ Starlark `min` and `max` buitins now allow a `key` callback, similarly to `sorted`. (#21960)

Acknowledgements:

This release contains contributions from many people at Google, as well as bazel.build machine account, Brentley Jones, Cameron Martin, Daniel Wagner-Hall, Douglas Thor, Fabian Meumertzheim, George Gensure, hvd, Isaac Torres, Keith Smiley, Mark Elliot, oquenchil, Romain Chossart, Son Luong Ngoc, Spencer Putt, Thomas Weischuh, Xdng Yng, Xùdōng Yáng, Zheng Wei Tan.

Release Notes:

Configurability:
+ aquery: `//foo:bar` now means "all configured targets with label `//foo:bar`" instead of "choose an arbitrary configured target with label `//foo:bar`". This is in line with cquery behavior. (bazelbuild#22135)
+ Added a new flag `--incompatible_disable_native_repo_rules` to disable native repo rule usage in WORKSPACE. All native repo rules now have a Starlark counterpart that can be used in both WORKSPACE and Bzlmod; see bazelbuild#22080 for more details. (bazelbuild#22203)
+ Starlark command-line flags can now be referred to through `alias` targets. (bazelbuild#22212)

ExternalDeps:
+ bzlmod `git_repository` now accepts the `strip_prefix` arg and passes it to the underlying `git_repository` call. (bazelbuild#22137)
+ Added a new `include()` directive to `MODULE.bazel` files, which allows the root module file to be divided into multiple segments. (bazelbuild#22204)
+ Fixed certain deadlocks in repo fetching with worker threads (`--experimental_worker_for_repo_fetching=auto`). (bazelbuild#22261)
+ `print` statements in module files are now only executed for the root module and modules subject to non-registry overrides (e.g. `local_path_override`). (bazelbuild#22263)
+ The new `refresh` value for `--lockfile_mode` behaves like the `update` mode, but additionally forces a refresh of mutable registry content (yanked versions and missing module versions) when switched to or from time to time while enabled. (bazelbuild#22371)
+ `Label` instances passed to `print` or `fail` as positional arguments are now formatted with apparent repository names (optimized for human readability). (bazelbuild#22460)
+ Changes to environment variables read via `getenv` now correctly invalidate module extensions. (bazelbuild#22541)
+ Git merge conflicts in `MODULE.bazel.lock` files can be resolved automatically. See https://bazel.build/external/lockfile#automatic-resolution for the required setup. (bazelbuild#22650)

OSS:
+ Bazel on Linux and BSD now respects the XDG_CACHE_HOME environment variable instead of assuming that ~/.cache/bazel is writable. (bazelbuild#21817)

Performance:
+ Paths in the Linux sandbox are now again identical to those outside the sandbox, even with `--incompatible_sandbox_hermetic_tmp`. (bazelbuild#22407)

Remote-Exec:
+ The combined coverage report produced via `--combined_report=lcov` is now announced on the BES via the new `CoverageReport` event. (bazelbuild#22327)
+ The compact and full execution logs now contain start times for spawns (if available). (bazelbuild#22341)

Rules-CPP:
+ The default Unix C++ toolchain now supports the `parse_headers` feature to validate header files with `--process_headers_in_dependencies`. (bazelbuild#22369)

Starlark-Interpreter:
+ Starlark `min` and `max` buitins now allow a `key` callback, similarly to `sorted`. (bazelbuild#21960)

Acknowledgements:

This release contains contributions from many people at Google, as well as bazel.build machine account, Brentley Jones, Cameron Martin, Daniel Wagner-Hall, Douglas Thor, Fabian Meumertzheim, George Gensure, hvd, Isaac Torres, Keith Smiley, Mark Elliot, oquenchil, Romain Chossart, Son Luong Ngoc, Spencer Putt, Thomas Weischuh, Xdng Yng, Xùdōng Yáng, Zheng Wei Tan.

### What does this PR do?

Implements version checking to ensure developers use Bazelisk rather than a
Bazel binary directly in their PATH. The check verifies that the current Bazel
version exactly matches the version specified in `.bazelversion`.

### Motivation

Following the idiom recommended in the Bazelisk documentation, we want to
ensure that developers don't accidentally bypass Bazelisk by having a Bazel
binary in their PATH. This prevents version mismatches that can lead to
build inconsistencies across different environments.

Without this check, developers might unknowingly use a different Bazel version
than the one specified in `.bazelversion`, leading to:
- Subtle build failures or differences between local and CI builds
- Dependency resolution issues with bzlmod
- Incompatible flag usage between Bazel versions

### Implementation details

The solution uses a repository rule that:
1. Reads the required version from `.bazelversion` at repository evaluation time
2. Captures the current `native.bazel_version` (only available in repository context)
3. Generates a `defs.bzl` file that calls `versions.check()` with both versions
4. Is invoked from `bazel/tools/BUILD.bazel` to trigger evaluation

The repository rule is marked with:
- `configure = True`: Indicates this rule depends on the environment (Bazel version)
- `local = True`: Marks the rule as non-hermetic, preventing aggressive caching

These flags are critical because:
- Without `local = True`, Bazel would cache the repository across different
  Bazel versions, defeating the purpose of the check
- Without `configure = True`, the repository wouldn't be recognized as
  environment-dependent, leading to stale cached results when switching
  between different Bazel installations

The check can be manually refreshed without restarting the Bazel server using:
```bash
bazel fetch --force --repo=@check_bazel_version
```

### Describe how you validated your changes

Tested with correct Bazel version (8.4.2 via Bazelisk):
```bash
bazel build //...  # Success
```

Tested with wrong Bazel version (8.3.1):
```bash
/path/to/bazel-8.3.1 build //...
# Error: Current Bazel version is 8.3.1; expected at least 8.4.2
```

Verified that the check happens early in the build process, before any
meaningful work is done.

### Additional Notes

**References:**
- Bazelisk idiom: https://github.com/bazelbuild/bazelisk?tab=readme-ov-file#ensuring-that-your-developers-use-bazelisk-rather-than-bazel
- Example implementation: https://gerrit.googlesource.com/prolog-cafe/+/master/tools/bzl/bazelisk_version.bzl
- Repository rule caching: https://blog.bazel.build/2017/02/22/repository-invalidation.html
- `--lockfile_mode=refresh` for forcing dependency re-evaluation: bazelbuild/bazel#22371

**Lessons learned:**
1. Repository rules in bzlmod are lazy - they only evaluate when a target
   depends on them, requiring an explicit load and call in BUILD.bazel
2. The `local = True` attribute is essential for repository rules that depend
   on the local environment (Bazel version, environment variables, etc.) to
   prevent Bazel from reusing cached results across different environments
3. The `configure = True` attribute signals that this repository rule depends
   on configuration/environment, allowing `bazel fetch --configure` to
   specifically target such rules
4. With bzlmod, `native.bazel_version` is only available in repository rule
   context (repository_ctx), not in BUILD file context, requiring the two-step
   pattern of generating a .bzl file from the repository rule
5. Module extensions have lazy evaluation and cannot be used for eager checks
   like version verification without creating a dummy repository that forces
   their evaluation

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>

### What does this PR do?

Implements version checking to ensure developers use Bazelisk rather than a
Bazel binary directly in their PATH. The check verifies that the current Bazel
version exactly matches the version specified in `.bazelversion`.

### Motivation

Following the idiom recommended in the Bazelisk documentation, we want to
ensure that developers don't accidentally bypass Bazelisk by having a Bazel
binary in their PATH. This prevents version mismatches that can lead to
build inconsistencies across different environments.

Without this check, developers might unknowingly use a different Bazel version
than the one specified in `.bazelversion`, leading to:
- Subtle build failures or differences between local and CI builds
- Dependency resolution issues with bzlmod
- Incompatible flag usage between Bazel versions

### Implementation details

The solution uses a repository rule that:
1. Reads the required version from `.bazelversion` at repository evaluation time
2. Captures the current `native.bazel_version` (only available in repository context)
3. Generates a `defs.bzl` file that calls `versions.check()` with both versions
4. Is invoked from `bazel/tools/BUILD.bazel` to trigger evaluation

The repository rule is marked with:
- `configure = True`: Indicates this rule depends on the environment (Bazel version)
- `local = True`: Marks the rule as non-hermetic, preventing aggressive caching

These flags are critical because:
- Without `local = True`, Bazel would cache the repository across different
  Bazel versions, defeating the purpose of the check
- Without `configure = True`, the repository wouldn't be recognized as
  environment-dependent, leading to stale cached results when switching
  between different Bazel installations

The check can be manually refreshed without restarting the Bazel server using:
```bash
bazel fetch --force --repo=@check_bazel_version
```

### Describe how you validated your changes

Tested with correct Bazel version (8.4.2 via Bazelisk):
```bash
bazel build //...  # Success
```

Tested with wrong Bazel version (8.3.1):
```bash
/path/to/bazel-8.3.1 build //...
# Error: Current Bazel version is 8.3.1; expected at least 8.4.2
```

Verified that the check happens early in the build process, before any
meaningful work is done.

### Additional Notes

**References:**
- Bazelisk idiom: https://github.com/bazelbuild/bazelisk?tab=readme-ov-file#ensuring-that-your-developers-use-bazelisk-rather-than-bazel
- Example implementation: https://gerrit.googlesource.com/prolog-cafe/+/master/tools/bzl/bazelisk_version.bzl
- Repository rule caching: https://blog.bazel.build/2017/02/22/repository-invalidation.html
- `--lockfile_mode=refresh` for forcing dependency re-evaluation: bazelbuild/bazel#22371

**Lessons learned:**
1. Repository rules in bzlmod are lazy - they only evaluate when a target
   depends on them, requiring an explicit load and call in BUILD.bazel
2. The `local = True` attribute is essential for repository rules that depend
   on the local environment (Bazel version, environment variables, etc.) to
   prevent Bazel from reusing cached results across different environments
3. The `configure = True` attribute signals that this repository rule depends
   on configuration/environment, allowing `bazel fetch --configure` to
   specifically target such rules
4. With bzlmod, `native.bazel_version` is only available in repository rule
   context (repository_ctx), not in BUILD file context, requiring the two-step
   pattern of generating a .bzl file from the repository rule
5. Module extensions have lazy evaluation and cannot be used for eager checks
   like version verification without creating a dummy repository that forces
   their evaluation

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>

### What does this PR do?

Implements version checking to ensure developers use Bazelisk rather than a
Bazel binary directly in their PATH. The check verifies that the current Bazel
version exactly matches the version specified in `.bazelversion`.

### Motivation

Following the idiom recommended in the Bazelisk documentation, we want to
ensure that developers don't accidentally bypass Bazelisk by having a Bazel
binary in their PATH. This prevents version mismatches that can lead to
build inconsistencies across different environments.

Without this check, developers might unknowingly use a different Bazel version
than the one specified in `.bazelversion`, leading to:
- Subtle build failures or differences between local and CI builds
- Dependency resolution issues with bzlmod
- Incompatible flag usage between Bazel versions

### Implementation details

The solution uses a repository rule that:
1. Reads the required version from `.bazelversion` at repository evaluation time
2. Captures the current `native.bazel_version` (only available in repository context)
3. Generates a `defs.bzl` file that calls `versions.check()` with both versions
4. Is invoked from `bazel/tools/BUILD.bazel` to trigger evaluation

The repository rule is marked with:
- `configure = True`: Indicates this rule depends on the environment (Bazel version)
- `local = True`: Marks the rule as non-hermetic, preventing aggressive caching

These flags are critical because:
- Without `local = True`, Bazel would cache the repository across different
  Bazel versions, defeating the purpose of the check
- Without `configure = True`, the repository wouldn't be recognized as
  environment-dependent, leading to stale cached results when switching
  between different Bazel installations

The check can be manually refreshed without restarting the Bazel server using:
```bash
bazel fetch --force --repo=@check_bazel_version
```

### Describe how you validated your changes

Tested with correct Bazel version (8.4.2 via Bazelisk):
```bash
bazel build //...  # Success
```

Tested with wrong Bazel version (8.3.1):
```bash
/path/to/bazel-8.3.1 build //...
# Error: Current Bazel version is 8.3.1; expected at least 8.4.2
```

Verified that the check happens early in the build process, before any
meaningful work is done.

### Additional Notes

**References:**
- Bazelisk idiom: https://github.com/bazelbuild/bazelisk?tab=readme-ov-file#ensuring-that-your-developers-use-bazelisk-rather-than-bazel
- Example implementation: https://gerrit.googlesource.com/prolog-cafe/+/master/tools/bzl/bazelisk_version.bzl
- Repository rule caching: https://blog.bazel.build/2017/02/22/repository-invalidation.html
- `--lockfile_mode=refresh` for forcing dependency re-evaluation: bazelbuild/bazel#22371

**Lessons learned:**
1. Repository rules in bzlmod are lazy - they only evaluate when a target
   depends on them, requiring an explicit load and call in BUILD.bazel
2. The `local = True` attribute is essential for repository rules that depend
   on the local environment (Bazel version, environment variables, etc.) to
   prevent Bazel from reusing cached results across different environments
3. The `configure = True` attribute signals that this repository rule depends
   on configuration/environment, allowing `bazel fetch --configure` to
   specifically target such rules
4. With bzlmod, `native.bazel_version` is only available in repository rule
   context (repository_ctx), not in BUILD file context, requiring the two-step
   pattern of generating a .bzl file from the repository rule
5. Module extensions have lazy evaluation and cannot be used for eager checks
   like version verification without creating a dummy repository that forces
   their evaluation

### What does this PR do?

Implements version checking to ensure developers use Bazelisk rather than a
Bazel binary directly in their PATH. The check verifies that the current Bazel
version exactly matches the version specified in `.bazelversion`.

### Motivation

Following the idiom recommended in the Bazelisk documentation, we want to
ensure that developers don't accidentally bypass Bazelisk by having a Bazel
binary in their PATH. This prevents version mismatches that can lead to
build inconsistencies across different environments.

Without this check, developers might unknowingly use a different Bazel version
than the one specified in `.bazelversion`, leading to:
- Subtle build failures or differences between local and CI builds
- Dependency resolution issues with bzlmod
- Incompatible flag usage between Bazel versions

### Implementation details

The solution uses a repository rule that:
1. Reads the required version from `.bazelversion` at repository evaluation time
2. Captures the current `native.bazel_version` (only available in repository context)
3. Generates a `defs.bzl` file that calls `versions.check()` with both versions
4. Is invoked from `bazel/tools/BUILD.bazel` to trigger evaluation

The repository rule is marked with:
- `configure = True`: Indicates this rule depends on the environment (Bazel version)
- `local = True`: Marks the rule as non-hermetic, preventing aggressive caching

These flags are critical because:
- Without `local = True`, Bazel would cache the repository across different
  Bazel versions, defeating the purpose of the check
- Without `configure = True`, the repository wouldn't be recognized as
  environment-dependent, leading to stale cached results when switching
  between different Bazel installations

The check can be manually refreshed without restarting the Bazel server using:
```bash
bazel fetch --force --repo=@check_bazel_version
```

### Describe how you validated your changes

Tested with correct Bazel version (8.4.2 via Bazelisk):
```bash
bazel build //...  # Success
```

Tested with wrong Bazel version (8.3.1):
```bash
/path/to/bazel-8.3.1 build //...
# Error: Current Bazel version is 8.3.1; expected at least 8.4.2
```

Verified that the check happens early in the build process, before any
meaningful work is done.

### Additional Notes

**References:**
- Bazelisk idiom: https://github.com/bazelbuild/bazelisk?tab=readme-ov-file#ensuring-that-your-developers-use-bazelisk-rather-than-bazel
- Example implementation: https://gerrit.googlesource.com/prolog-cafe/+/master/tools/bzl/bazelisk_version.bzl
- Repository rule caching: https://blog.bazel.build/2017/02/22/repository-invalidation.html
- `--lockfile_mode=refresh` for forcing dependency re-evaluation: bazelbuild/bazel#22371

**Lessons learned:**
1. Repository rules in bzlmod are lazy - they only evaluate when a target
   depends on them, requiring an explicit load and call in BUILD.bazel
2. The `local = True` attribute is essential for repository rules that depend
   on the local environment (Bazel version, environment variables, etc.) to
   prevent Bazel from reusing cached results across different environments
3. The `configure = True` attribute signals that this repository rule depends
   on configuration/environment, allowing `bazel fetch --configure` to
   specifically target such rules
4. With bzlmod, `native.bazel_version` is only available in repository rule
   context (repository_ctx), not in BUILD file context, requiring the two-step
   pattern of generating a .bzl file from the repository rule
5. Module extensions have lazy evaluation and cannot be used for eager checks
   like version verification without creating a dummy repository that forces
   their evaluation