Prepare TensorBoard 2.22

[psamanoelton]

Summary

Prepare TensorBoard 2.22 for compatibility with TensorFlow 2.22.0rc0.

This change:

• Updates the Bazel TensorFlow compatibility baseline from 2.21.0 to 2.22.0rc0.
• Regenerates the locked Python dependency graph and corresponding Bzlmod lockfile.
• Synchronizes TensorBoard's vendored compatibility protos with TensorFlow 2.22.0rc0.
• Regenerates the Rust data server proto descriptor.
• Updates development documentation and the documented protobuf compatibility baseline.

TensorBoard's version and the CI TensorFlow pin are intentionally unchanged. Those release-preparation changes will be handled in separate PRs.

Motivation

TensorBoard maintains local copies of several TensorFlow proto definitions so it can operate without a TensorFlow installation. These protos and the Bazel Python dependency graph need to match TensorFlow 2.22 before preparing the TensorBoard 2.22 release.

TensorFlow 2.22 also changes part of its Python dependency graph, including its transition from keras to keras-nightly.

Changes

TensorFlow dependency baseline

• Updates requirements_bazel.in from tensorflow==2.21.0 to tensorflow==2.22.0rc0.
• Regenerates requirements_bazel_lock.txt.
• Regenerates MODULE.bazel.lock.
• Updates the resolved dependency graph for keras-nightly and its transitive dependencies.
• Keeps TensorBoard's protobuf runtime constraint at protobuf>=6.31.1,<8.0.0, which remains compatible with TensorFlow 2.22.

TensorFlow compatibility protos

• Synchronizes the vendored protos under tensorboard/compat/proto with TensorFlow 2.22.0rc0.
• Includes the latest ConfigProto batching options and upstream proto formatting and license updates.
• Updates the proto source-version documentation.
• Regenerates tensorboard/data/server/descriptor.bin.

The protos were synchronized from:

• TensorFlow tag: v2.22.0-rc0
• TensorFlow commit: 160ece53b82229862412699ff770232d2c3e1313

Documentation

• Updates the development environment instructions to use TensorFlow 2.22.0rc0.
• Documents TensorFlow 2.22 as the current compatibility baseline.

Validation

Validated on Linux using the tb-ci-py310 Docker environment with Bazel 8.7.0 and Python 3.10.

The following checks passed:

bazel mod graph --lockfile_mode=error
bazel fetch //tensorboard/...

bazel run //tensorboard/data/server:update_protos

bazel test --test_output=errors \
  //tensorboard/compat/proto:proto_test \
  //tensorboard/data/server:update_protos_test \
  //tensorboard/compat:compat_test \
  //tensorboard:data_compat_test \
  //tensorboard:dataclass_compat_test \
  //tensorboard/summary/writer:event_file_writer_test \
  //tensorboard/plugins/scalar:summary_test \
  //tensorboard/plugins/text:summary_test \
  //tensorboard/plugins/histogram:summary_test

All 9 targeted tests passed.
The pip package was also built and smoke-tested with TensorFlow 2.22.0rc0:

bazel build //tensorboard/pip_package:test_pip_package

./bazel-bin/tensorboard/pip_package/test_pip_package \
  --tf-version "tensorflow==2.22.0rc0"

The smoke test passed, including TensorBoard serving, projector and HParams imports, summary APIs, and TensorFlow summary import-order checks.
Buildifier, license, whitespace, and diff hygiene checks also passed.

Note:
In future PRs the tf pin in ci.yml will be updated like in: bf23338

[cdavalos7]

I noticed a discrepancy here. The PR description says the CI TensorFlow pin is intentionally unchanged, and .github/workflows/ci.yml still has TENSORFLOW_VERSION: 'tf-nightly'. The comment in requirements_bazel.in also still says "currently tf-nightly" Should this line keep saying tf-nightly until the CI pin is updated?

[psamanoelton]

Good catch. The CI-selected package remains tf-nightly in this PR, so I’ll correct this line to match ci.yml and requirements_bazel.in. The CI TensorFlow pin will be handled in a separate release-preparation PR.

[cdavalos7]

Curious about. This changes the dev setup from TF nightly to a pinned release candidate. Is that intentional going forward? If so, is the plan to update it to 2.22.0 once the final release is out, so the docs don’t point to an rc0 for long?

[psamanoelton]

This is not intended to change the ongoing TensorBoard-at-HEAD developer workflow. I’ll restore this section to tf-nightly; tensorflow==2.22.0rc0 will remain the Bazel compatibility baseline and the version used for the targeted 2.22 smoke test. The release pin will be handled separately, consistent with the 2.21 release process.

[cdavalos7]

Just to confirm: this pins a keras nightly build from October 2025. Is this exactly what tensorflow==2.22.0rc0 requires, or could the resolver be picking an older dev build than intended?

[psamanoelton]

TensorFlow 2.22.0rc0 declares keras-nightly>=3.12.0.dev, rather than an exact dated build. Since this lock targets Python 3.10 and newer Keras nightly series require Python 3.11+, uv resolves the latest Python-3.10-compatible build, 3.12.0.dev2025100703. I reproduced the same selection with Python 3.10 and uv==0.5.31 in the Linux Docker environment, and the TF 2.22.0rc0 smoke test passed.

[cdavalos7]

click only depends on colorama on Windows, but it shows up here without a platform marker, and it wasn’t in the lock before. Was the lock generated with the uv==0.5.31 command from DEVELOPMENT.md, or with a different uv version or flags? Not a blocker, just want to make sure the documented regeneration steps reproduce this file.

[psamanoelton]

I reproduced the command with Python 3.10 and uv==0.5.31 in the Linux Docker image, and the Linux resolution omits colorama. I’ll regenerate the requirements lock and corresponding Bzlmod lock in Docker. I’ll also align the documented invocation with the directory used to generate the lock so the instructions reproduce its contents and annotations.

[cdavalos7]

Just a few comments to double check, no blocking