build: bump max bazel version from 5.4.0 to end of 6.x series #6183
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
arcra
approved these changes
Feb 8, 2023
yatbear
pushed a commit
to yatbear/tensorboard
that referenced
this pull request
Mar 27, 2023
…flow#6183) We inadvertently resolved tensorflow#6115 via tensorflow#6147, so we no longer need to pin to a maximum Bazel version of 5.4.0. That said, I think it's still a good idea to retain a maximum compatible version, since Bazel major version upgrades have reliably resulted in our build breaking in the past. That way, when Bazel 7.0.0 arrives, we'll get a clean error message, and if we then try to remove the pin, we'll either be pleasantly surprised that it's fine, or we'll be expecting a build failure and know the cause (rather than encountering a build failure during a routine build, and then wasting time debugging before realizing Bazel was silently upgraded). Putting this in place now also ensures this protection extends to older commits, rather than doing it reactively, which then relies on people syncing past that commit before trying to build. Tested via `USE_BAZEL_VERSION=6.0.0 bazel run tensorboard` (w/ bazel set to bazelisk) and confirmed it builds successfully and runs apparently normally.
dna2github
pushed a commit
to dna2fork/tensorboard
that referenced
this pull request
May 1, 2023
…flow#6183) We inadvertently resolved tensorflow#6115 via tensorflow#6147, so we no longer need to pin to a maximum Bazel version of 5.4.0. That said, I think it's still a good idea to retain a maximum compatible version, since Bazel major version upgrades have reliably resulted in our build breaking in the past. That way, when Bazel 7.0.0 arrives, we'll get a clean error message, and if we then try to remove the pin, we'll either be pleasantly surprised that it's fine, or we'll be expecting a build failure and know the cause (rather than encountering a build failure during a routine build, and then wasting time debugging before realizing Bazel was silently upgraded). Putting this in place now also ensures this protection extends to older commits, rather than doing it reactively, which then relies on people syncing past that commit before trying to build. Tested via `USE_BAZEL_VERSION=6.0.0 bazel run tensorboard` (w/ bazel set to bazelisk) and confirmed it builds successfully and runs apparently normally.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We inadvertently resolved #6115 via #6147, so we no longer need to pin to a maximum Bazel version of 5.4.0.
That said, I think it's still a good idea to retain a maximum compatible version, since Bazel major version upgrades have reliably resulted in our build breaking in the past. That way, when Bazel 7.0.0 arrives, we'll get a clean error message, and if we then try to remove the pin, we'll either be pleasantly surprised that it's fine, or we'll be expecting a build failure and know the cause (rather than encountering a build failure during a routine build, and then wasting time debugging before realizing Bazel was silently upgraded).
Putting this in place now also ensures this protection extends to older commits, rather than doing it reactively, which then relies on people syncing past that commit before trying to build.
Tested via
USE_BAZEL_VERSION=6.0.0 bazel run tensorboard(w/ bazel set to bazelisk) and confirmed it builds successfully and runs apparently normally.