Bazel 1.0, Google’s polyglot build system switches to semantic versioning for better stability

3 min read

The Bazel team announced the release of Bazel 1.0, last week. The team calls this version a “stability milestone” as it tries to address the stability concerns associated with Bazel by switching to semantic versioning. Along with this change, Bazel 1.0 features new genrule support, C++ and Java-related improvements, gRPC connections with default TLS enabled, and more.

Bazel is the open-source version of the Blaze tool that Google uses internally. It is a polyglot build system that enables you to automate software building and testing. It provides features like reproducibility via sandboxing, distributed caching, static analysis of build dependencies, uniform CLI for builds and tests, and more.

Key updates in Bazel 1.0


  • A genrule generates one or more files based on a user-defined Bash command. Starting with Bazel 1.0, genrule supports cmd_bash, cmd_ps, and cmd_bat attributes for better integration on Windows.
  • You can now get a new generated DEF file from the def_file output group of cc_library.


  • Previously, tags were not being propagated from a Bazel’s target to the action’s execution requirements. In Bazel 1.0, this is possible with the help of the –experimental_allow_tags_propagation flag.
  • A rule consists of a series of actions that Bazel performs on inputs to produce a set of outputs. Now all rules have a default exec_properties attribute just like the one on a platform rule.
  • Starting with Bazel 1.0, all gRPC connections from Bazel will have TLS enabled by default. You can disable TLS by going to the grpc:// scheme in your URIs.


  • The config_setting general rule matches an expected configuration state for the purpose of triggering configurable attributes. With Bazel 1.0 release, it can now check multiple values on “–foo=firstVal –foo=secondVal …“-style flags.
  • This release comes with –enable_platform_specific_config that enable flags in bazelrc according to your host platform.


  • The cc_* rules now support non-transitive defines via a local_defines attribute. This attribute returns the set of defines needed to compile a particular target.
  • Bazel 1.0 comes with support for ThinLTO builds, the new link-time optimization (LTO) compilation type, on Linux for Clang versions 6.0 or above. You can enable ThinLTO via –features=thin_lto.


  • The Java-Starlark API, java_common.create_provider is now removed. Also, the JavaInfo() legacy arguments including actions, sources, source_jars, use_ijar, java_toolchain, and host_javabase are removed.
  • Starting with Bazel 1.0, maven_jar and maven_server do not permit the use of plain HTTP URLs without a specified checksum. If you are using maven_jar it recommends switching to rules_jvm_external for transitive dependency management.

The team has also advised that developers check the compatibility of their codebase by running bazelisk –migrate or by building their code with Bazel 0.29.1 and a list of flags before they upgrade to Bazel 1.0.

These were some of the updates in Bazel 1.0. Check out the official announcement to know what else has shipped in this release.

Read Next

Rust 1.38 releases with pipelined compilation for better parallelism while building a multi-crate project

Pivotal open sources kpack, a Kubernetes-native image build service

Mozilla releases WebThings Gateway 0.9 experimental builds targeting Turris Omnia and Raspberry Pi 4

Introducing Weld, a runtime written in Rust and LLVM for cross-library optimizations

LLVM 9 releases with official RISC-V target support, asm goto, Clang 9, and more