4 ms·

The lack of backwards compatibility between Bazel versions has been the deal-killer for me thus far. Old build instructions should work with newer releases of t

The lack of backwards compatibility between Bazel versions has been the deal-killer for me thus far. Old build instructions should work with newer releases of the same tools. It's important for the tools to remain compatible because you can't change the instructions contained in old releases. I hope the release of 1.0 is an indication that Bazel is taking interface stability more seriously.

ageofwant 7y ago
Right. Every time I build tensorflow I have to build bazel first, or get the bazel version for the tf version. I have to say, having used a number of Google's tools over the years: basel, coral sdk, maps api and perhaps others, I'm always surprised at how 'how ya doing' the experience is. Don't get me wrong, I appreciate their tools and its openness, but I wish Google spend a bit more time doing software engineering, and less throwing shit against a wall ascertaining stickiness.
- philwo 7y ago
  > Every time I build tensorflow I have to build bazel first, or get the bazel version for the tf version. This is fixed now: https://github.com/tensorflow/tensorflow/commit/991aec351b574c4ec9157b9e557fb0f7f53bc4d9 https://github.com/tensorflow/tensorflow/commit/991aec351b57... If you use Bazelisk (https://github.com/bazelbuild/bazelisk https://github.com/bazelbuild/bazelisk), you'll automatically get the matching Bazel version for TensorFlow in the future (and all other projects that have adopted the .bazelversion file).
  - slavik81 7y ago
    Awesome. Bazelisk provides exactly the sort of compatibility I was hoping to see. Though, manually specifying a maximum Bazel version doesn't seem like it should be necessary. The authors of Bazel know what features they have changed since the version specified as the minimum, and Bazel itself knows what features the BUILD file uses. That information together could be used to calculate the maximum version.
jingwen 7y ago
Yes. 1.0 indicates the beginning of semantic versioning, which was not in place during the alpha and beta phases.
- shusson 7y ago
  Exactly this. It's not fair to complain about breaking changes in a product pre 1.0. Also, unless they had wildly different versioning pre 1.0, they could have just said "we are releasing 1.0". semver already states that 0.y.z should not be considered a stable API [1]. [1] https://github.com/semver/semver/blob/master/semver.md https://github.com/semver/semver/blob/master/semver.md

ageofwant 7y ago

Right. Every time I build tensorflow I have to build bazel first, or get the bazel version for the tf version. I have to say, having used a number of Google's tools over the years: basel, coral sdk, maps api and perhaps others, I'm always surprised at how 'how ya doing' the experience is. Don't get me wrong, I appreciate their tools and its openness, but I wish Google spend a bit more time doing software engineering, and less throwing shit against a wall ascertaining stickiness.

philwo 7y ago
> Every time I build tensorflow I have to build bazel first, or get the bazel version for the tf version. This is fixed now: https://github.com/tensorflow/tensorflow/commit/991aec351b574c4ec9157b9e557fb0f7f53bc4d9 https://github.com/tensorflow/tensorflow/commit/991aec351b57... If you use Bazelisk (https://github.com/bazelbuild/bazelisk https://github.com/bazelbuild/bazelisk), you'll automatically get the matching Bazel version for TensorFlow in the future (and all other projects that have adopted the .bazelversion file).
- slavik81 7y ago
  Awesome. Bazelisk provides exactly the sort of compatibility I was hoping to see. Though, manually specifying a maximum Bazel version doesn't seem like it should be necessary. The authors of Bazel know what features they have changed since the version specified as the minimum, and Bazel itself knows what features the BUILD file uses. That information together could be used to calculate the maximum version.

jingwen 7y ago

Yes. 1.0 indicates the beginning of semantic versioning, which was not in place during the alpha and beta phases.

shusson 7y ago
Exactly this. It's not fair to complain about breaking changes in a product pre 1.0. Also, unless they had wildly different versioning pre 1.0, they could have just said "we are releasing 1.0". semver already states that 0.y.z should not be considered a stable API [1]. [1] https://github.com/semver/semver/blob/master/semver.md https://github.com/semver/semver/blob/master/semver.md