Release 2.0 - December 2019

[dslomov]

Cut date 2019-12-02.

[aehlig]

Status of Bazel 2.0

• Target baseline: Dec 2, 2019
• Expected release date: Dec 16, 2019
• List of release blockers

To report a release-blocking bug, please file a bug using the Release blocker label, and cc me.

Task list:

• Update GitHub issues for incompatible changes
• Pick release baseline: db0e32c
• Create release candidate: https://releases.bazel.build/2.0.0/rc2/index.html
• Check downstream projects: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1303
• Create draft release announcement
• Send for review the release announcement PR: Bazel 2.0 bazel-blog#210
• Push the release, notify package maintainers.
• Update the documentation
• Push the blog post
• Update the release page

[aehlig]

The nightly tests of the last days look equally broken—mainly due to downstream projects not aware of the removal of native maven_jar. So we can as well take the latest nightly; since the only commit after the latest nightly is a bug fix, I will include it as well. So, I'll try 807ed23 as a baseline, but will slip it, if the next nightly is better.

[aehlig]

Slipping baseline to db0e32c to fix the release pipeline.

[aehlig]

Created rc2 with baseline db0e32c and no cherry-picks: https://releases.bazel.build/2.0.0/rc2/index.html

[aehlig]

Run of downstream projects pretty broken as a lot of projects are not yet prepared for the removal of native maven_jar.

[jin]

On maven_jar breakages:

• IntelliJ plugins tests depend on bazel-integration-testing, which depends on maven_jar.
  • Migrate maven_jar to jvm_maven_import_external bazel-integration-testing#159
  • Update bazel-integration-testing to prepare for Bazel 2.0. intellij#1451
• I'm in progress of migrating rules_scala.
  • Convert maven_jar to jvm_maven_import_external rules_scala#889
• rules_docker depends on rules_groovy, which depends on maven_jar. I'll take care of that as well.
  • Remove maven_server to prepare for Bazel 2.0 rules_groovy#43
  • Update rules_groovy to prepare for Bazel 2.0 rules_docker#1307
• Protobuf is also broken.
  • Migrate from maven_jar to jvm_maven_import_external to prepare for Bazel 2.0 protocolbuffers/protobuf#6970
• bazel-examples
  • Remove stray dependencies call in FCM example examples#131

[jin]

Looks like #10000 missed the baseline cut by a few hours. Could we please cherry-pick 85e84f7 into the release?

@bchang @donaldchai

[aehlig]

Creating rc3 with same baseline and 85e84f7 cherry-picked.

[jin]

Thanks @aehlig!

[aehlig]

• rc3 available at https://releases.bazel.build/2.0.0/rc3/index.html
• run of downstream projects at https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1301

[davido]

Protobuf is also broken.
protocolbuffers/protobuf#6970

The issue with replacing of native maven_jar usages with {java|jvm}_maven_import_external is that it is conflicting with --incompatible_load_java_rules_from_bzl and is producing broken code. It's using java_import internally, but is not generating this line:

# This line is missing
load("@rules_java//java:defs.bzl", "java_import")

The breakage was flagged by @ejona86 in #8746 (comment) and as the consequence, this issue was filed: [1].

IOW, there is currently no way forward strategy for such replacement. That why, the migration of native maven_jar is not ready yet, and consistently, the right course of action would be:

a. Try to fix: [1] in upcoming 2.0 release.
b. In case a. is not possible, roll back removal of maven_jar in Bazel 2.0 and schedule it for a later release, but only until after [1] is fixed.

[1] #10046

[jin]

incompatible_load_java_rules_from_bzl hasn't been enabled in Bazel 2.0. We can definitely make sure that that rules_java is automatically loaded in 2.x, and ready by the time incompatible_load_java_rules_from_bzl is enforced.

We're also extracting the Starlark jvm rules out of Bazel (bazel-contrib/rules_jvm_external#299), which allows for a separate release cadence from Bazel.

[davido]

I tried using Bazel 2.0.0rc3 but after fetching bazel-2.0.0rc3-installer-linux-x86_64.sh and installing it locally, it is telling me that I have to download bazel binary again. I filed this issue.

[aehlig]

New run on the downstream projects, as some have been fixed: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1303

[jin]

@aehlig all of the known failures from maven_jar are now migrated, AFAICT.

[Kernald]

I just spotted a typo in the new .bazelversion handling: #10388 might be interesting to cherry-pick (absolutely not critical though, I don't know what's the policy on those kind of minor fixes after a cut)

[philwo]

Hi @aehlig,

please cherry-pick these commits into rc4 to fix the reported issues with the wrapper:

• 84eae2f
• d5ae460

[aehlig]

Creating rc4 with baseline db0e32c and cherry picks

• 85e84f7
• 84eae2f
• d5ae460

[aehlig]

• rc4 is available at https://releases.bazel.build/2.0.0/rc4/index.html
• run of the downstream projects at https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1319

[aehlig]

Looking at the downstream projects, the following is to be noted.

• There was some infrastructure failure, hence the retries; @philwo is investigating the root cause, but in either way, this is unrelated to bazel release candidate.
• rules_cc is a known issue. bazelbuild/rules_cc@cd7e8a6 adds a test for a feature that was only introduced in 949e806 and hence is not part of bazel 2.0.0. Users who which to use rules_cc with bazel 2.0.0 should use version bazelbuild/rules_cc@01d4a48 of rules_cc.
• rules_rust is broken in stardoc invocation; this invocation makes invalid assumptions of how to map repositories to paths in the output root: Stardoc documentation generation failed: File all.bzl imported '@io_bazel_rules_rust//rust:toolchain.bzl', yet external/io_bazel_rules_rust/rust/toolchain.bzl was not found, even at roots [., external/docs]. despite @io_bazel_rules_rust being the main repository.
• rules_nodejs is also broken in stardoc like rules_rust and, on top, stardoc rightly complains that the doc string for node_repositories does not have a one-line summary.

So, according to our current policy, these breakages are not blocking. So, unless new problems are reported on the bug, I intend to release on late Thursday or early Friday (Munich time).

[aehlig]

Bazel 2.0 has been released, see https://github.com/bazelbuild/bazel/releases/tag/2.0.0

[aehlig]

cc @vbatts @petemounce @excitoon as you're maintaining a bazel package

[uri-canva]

cc @mboes, @danjuv

[philwo]

@dslomov If you agree, I could create a patch release for Bazel 2.0 with 2a8cc70 included to address #10356 (comment).

[dslomov]

@philwo sgtm

[philwo]

I'm preparing Bazel 2.0.1 with two cherry-picks:

9a823d9: Prevent NPE on backwards seek on Chunker.
2a8cc70: Do not fail or print errors when Shellzelisk cannot find a requested Bazel binary, if tools/bazel exists.

RELEASE_NUMBER=2.0.1
BASELINE_COMMIT=50514fc6c125750d7063d7feea2c302a44d2db6e
git clone https://github.com/bazelbuild/bazel.git ~/bazel-release-$RELEASE_NUMBER
cd ~/bazel-release-$RELEASE_NUMBER
scripts/release/release.sh create $RELEASE_NUMBER $BASELINE_COMMIT \
    9a823d9dab82631ff4600eff38d597807e8d1221 \
    2a8cc7075f741721563efd9dc050ca3458cde30b

[philwo]

Bazel 2.0.1rc1 is now available for those that want to try it out.

You can download it from:
https://releases.bazel.build/2.0.1/rc1/index.html

[chenrui333]

Just curious what might be the reason why people cannot move to Bazel 2.1.0?

[philwo]

@chenrui333 There shouldn't be any reason (there are no intentionally breaking changes, or accidental breaking changes that we could detect via our CI), but just in case that Bazel 2.1 has a regression for some Bazel 2.0 users, I think the patch release is nice and doesn't do harm. :) It might also be easier to qualify for users who have stricter validations for their upgrade, e.g. in case of industry regulations.

Personally, I would of course just upgrade to Bazel 2.1. 😊

[chenrui333]

I am mostly thinking from maintenance efforts from you guys perspective (you guys are doing awesome job 👍 ).

Thanks for clarifying it!

[vbatts]

i've cut the release for fedora/centos/RHEL as a package named 'bazel2' so folks can opt-in to the upgrade.