Bazel 2.0

#1

Post by the_alchemist » Mon, Dec 23, 2019, 1:17 PM UTC

Bazel 2.0
blog.bazel.build

Re: Bazel 2.0

#2

Post by kylecordes » Mon, Dec 23, 2019, 2:36 PM UTC

As with many projects using semantic versioning, the major version bump just signifies there are some breaking changes. Most projects will just switch from 1.x to 2 work noticing.

Re: Bazel 2.0

#3

Post by kryptiskt » Mon, Dec 23, 2019, 2:50 PM UTC

kylecordes wrote: post #2

As with many projects using semantic versioning, the major version bump just signifies there are some breaking changes. Most projects will just switch from 1.x to 2 work noticing.

That "changed some corner cases that likely won't affect you" and "rewrite it all" looks the same in SemVer makes it next to useless, not that any other system would be better. We just shouldn't have any expectations about version numbers conveying much information.

Re: Bazel 2.0

#4

Post by zegl » Mon, Dec 23, 2019, 2:52 PM UTC

kylecordes wrote: post #2

As with many projects using semantic versioning, the major version bump just signifies there are some breaking changes. Most projects will just switch from 1.x to 2 work noticing.

I can’t understand why the Bazel team hasn’t learnt from Go team how to handle breaking changes. Bazel is an amazing piece of tech, but it can definitely be a lot of work to keep up to date.

Re: Bazel 2.0

#5

Post by oconnor663 » Mon, Dec 23, 2019, 3:08 PM UTC

zegl wrote: post #4

kylecordes wrote: post #2

As with many projects using semantic versioning, the major version bump just signifies there are some breaking changes. Most projects will just switch from 1.x to 2 work noticing.

I can’t understand why the Bazel team hasn’t learnt from Go team how to handle breaking changes. Bazel is an amazing piece of tech, but it can definitely be a lot of work to keep up to date.

What's the Go strategy? Just never have breaking changes?

Re: Bazel 2.0

#6

Post by JadeNB » Mon, Dec 23, 2019, 3:11 PM UTC

I didn't know, so, just for anyone else who didn't:

> Bazel is an open-source build and test tool similar to Make, Maven, and Gradle. It uses a human-readable, high-level build language. Bazel supports projects in multiple languages and builds outputs for multiple platforms. Bazel supports large codebases across multiple repositories, and large numbers of users.

Re: Bazel 2.0

#7

Post by ivanbakel » Mon, Dec 23, 2019, 3:12 PM UTC

kryptiskt wrote: post #3

kylecordes wrote: post #2

As with many projects using semantic versioning, the major version bump just signifies there are some breaking changes. Most projects will just switch from 1.x to 2 work noticing.

That "changed some corner cases that likely won't affect you" and "rewrite it all" looks the same in SemVer makes it next to useless, not that any other system would be better. We just shouldn't have any expectations about version numbers conveying much information.

How is SemVer next to useless? The major version bump informs you that you should go look up what breaking changes have occurred before you upgrade. It is inherently useful for under-approximating the "safe" range of versions of a piece of software that can be used, which is seen in practice in many package managers.

That it can't differentiate between those two cases is because it's not meant to. It's like complaining that the blurb of a novel is "next to useless" because it doesn't tell you the complete story in a detailed way over several hundred pages.

Re: Bazel 2.0

#8

Post by mirekrusin » Mon, Dec 23, 2019, 3:14 PM UTC

oconnor663 wrote: post #5

zegl wrote: post #4

Earlier quoted context omitted.

I can’t understand why the Bazel team hasn’t learnt from Go team how to handle breaking changes. Bazel is an amazing piece of tech, but it can definitely be a lot of work to keep up to date.

What's the Go strategy? Just never have breaking changes?

Don’t break, wait. After a decade revisit.

Re: Bazel 2.0

#9

Post by jsolson » Mon, Dec 23, 2019, 3:15 PM UTC

zegl wrote: post #4

kylecordes wrote: post #2

As with many projects using semantic versioning, the major version bump just signifies there are some breaking changes. Most projects will just switch from 1.x to 2 work noticing.

I can’t understand why the Bazel team hasn’t learnt from Go team how to handle breaking changes. Bazel is an amazing piece of tech, but it can definitely be a lot of work to keep up to date.

I don't know the team specifically, but I suspect the difference comes down in part to Go open sourcing early in development, thus finding a bunch of the rough edges that exist outside Google's walled garden early in the project's life when there wasn't much compatibility _to_ break. Blaze was a mature project within Google for years before Bazel was opened up. Many of the breaking changes seem to be taking one-offs built for features within Google (e.g., the handling of protocol buffer rules) and building those in terms of more general and composeable features.

The net result is a Bazel (and Blaze) that are less burdened by the baggage of legacy, but the cost is a faster treadmill to keep pace with changes.

Re: Bazel 2.0

#10

Post by kylecordes » Mon, Dec 23, 2019, 3:18 PM UTC

kryptiskt wrote: post #3

kylecordes wrote: post #2

As with many projects using semantic versioning, the major version bump just signifies there are some breaking changes. Most projects will just switch from 1.x to 2 work noticing.

That "changed some corner cases that likely won't affect you" and "rewrite it all" looks the same in SemVer makes it next to useless, not that any other system would be better. We just shouldn't have any expectations about version numbers conveying much information.

Yes, and this is my biggest frustration with semver. it adds something valuable by communicating breaking changes, but it loses something else valuable, signaling the magnitude of the changes.

Hopefully in the coming years something will eclipse semver which solves both problems sufficiently. I don't know of any candidates offhand though.