Bazel: Release 4.0 - December 2020

[philwo]

Status of Bazel 4.0

• Target baseline: 2020-11-12
• Expected release date: 2021-01-18
• List of release blockers

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

Task list:

• [x] Update GitHub issues for incompatible changes
• [x] Pick release baseline: 37a429ad12b4c9e6a62dbae4881a1ff03b81ab40
• [x] Create release candidate: https://releases.bazel.build/4.0.0/rc10/
• [x] Check downstream projects:
• [x] [Create draft release announcement](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
• [x] Send for review the release announcement PR:
• [x] Push the release, notify package maintainers:
• [ ] Update the documentation
• [x] Push the blog post
• [x] Update the release page

[dws]

If this release includes breaking change e379ece1908aafc852f9227175dd3283312b4b82, then please ensure that the release has a relnote for it.
I became aware of this change because it broke an earlier version of a bazel-skylib PR that I've been working on.

[philwo]

Bazel 4.0.0rc1 created and pushed via:

scripts/release/release.sh create 4.0.0 cd3480e4d53160d20c634134d3917c4e53ac1c49
scripts/release/release.sh push

[philwo]

aaaaand it failed:

ERROR: /workdir/scripts/packages/BUILD:122:21: no such package 'scripts/fish': BUILD file not found in any of the following directories. Add a BUILD file to a directory to mark it as a package.
/workdir/scripts/fish and referenced by '//scripts/packages:with-jdk/install.sh'

I've seen this recently when building / testing Bazel locally and I think it's just a dangling reference somewhere in our BUILD files that we didn't clean up. Investigating.

[philwo]

git bisect says, this is the külprit: 20febacc0c02545684d3429fc21f28cf7ed8f461

[philwo]

scripts/release/release.sh create --force_rc=2 4.0.0 37a429ad12b4c9e6a62dbae4881a1ff03b81ab40
scripts/release/release.sh push

[philwo]

Release builds succeeded on:

• [x] Linux x86_64
• [x] macOS x86_64
• [x] Windows x86_64
• [x] Linux arm64

Next step pushing to GCS.

[philwo]

Pushed and announcement for 4.0.0rc2 sent to bazel-discuss! 🎉

[philwo]

List of proposed cherry-picks for 4.0.0rc3:

• [ ] https://github.com/bazelbuild/bazel/pull/12529

[meisterT]

Just to make you aware, #12574 is still under investigation but may make another cherry pick necessary.

[comius]

Just to make you aware, #12574 is still under investigation but may make another cherry pick necessary.

Java_tools 10.4 is already in baseline, so no cherry pick is necessary.

[wrowe]

@philwo Can this be added to the list of hard showstoppers? https://github.com/bazelbuild/bazel/issues/12545 is a regression that's been observed only since 3.7.0 release.

[meisterT]

12545 is fixed by a689d673abadf80f1efaf8ddaeee92d56fc2847b

[jin]

Jacoco crash reported in #12619 for rc2

[limdor]

@philwo in the context of LTS, is it already know what will happen with the bug fixes that should go to the next 4.x release without having to wait for 5.0? I would like to request a cherry-pick for 4.x LTS, I do not think is needed for release 4.0 because has been broken for a long time.

[comius]

Jacoco crash reported in #12619 for rc2

The crash was fixed by commit d90ec67, which may be cherry-picked .

[comius]

Another issue was discovered in Turbine, which affects Java 15 compilations (potentially also other versions) https://github.com/bazelbuild/bazel/issues/12605. The fix is more tricky, because we are already at java_tools v11.0, and I need to backport a fix to java_tools v10 and release v10.5. (and v11.1).

[Gormo]

We've seen an issue on Windows on 4.0.0rc2
ERROR: C:/####/BUILD.bazel:7:8: Executing genrule @##//####:generate_ids failed: Exec failed due to IOException: Cannot delete path '/dev/null': ERROR: src/main/native/windows/file-jni.cc(156): nativeDeletePath(\?\devnull): ERROR: src/main/native/windows/file.cc(624): DeletePath(\?\devnull): expected an absolute Windows path

Seen both triggered from a genrule and a regular rule.

We're still unsure exactly what is triggering this issue but it's currently stopping our migration to 4.0.0. Investigation ongoing but wanted to give you a heads up.

[comius]

Another issue was discovered in Turbine, which affects Java 15 compilations (potentially also other versions) #12605. The fix is more tricky, because we are already at java_tools v11.0, and I need to backport a fix to java_tools v10 and release v10.5. (and v11.1).

v10.5 release is in 4e5d0fd, which should also be cherry-picked
optionally also cherrypick 9a3552c, that is turbine_deploy.jar, it doesn't affect bazel binaries, but it might help the posterity

[philwo]

@Gormo Thanks for pointing that out. I checked with @meteorcloudy but it doesn't ring a bell.. we'll have to investigate further. If you find out anything, please let us know!

In the meantime I'll go ahead with 4.0.0rc3 so that the new cherry-picks get some exposure.

[jmillikin]

Would it be possible to cherry-pick https://github.com/bazelbuild/bazel/commit/8555789dd239a5ac229c1d9cee80b2a9f30b3bf7 into v4.0 ? If not, could it be queued up for the first v4.x patch release?

[philwo]

@jmillikin I'm currently not picky when it comes to cherry picks. 😏 Happy to add it.

[meteorcloudy]

ERROR: C:/####/BUILD.bazel:7:8: Executing genrule @##//####:generate_ids failed: Exec failed due to IOException: Cannot delete path '/dev/null': ERROR: src/main/native/windows/file-jni.cc(156): nativeDeletePath(\?\devnull): ERROR: src/main/native/windows/file.cc(624): DeletePath(\?\devnull): expected an absolute Windows path

@Gormo If you can provide a minimal repro case, I'm happy to help bisect and probably send a fix for this issue.

[philwo]

Building 4.0.0rc3 now:

scripts/release/release.sh create --force_rc=3 4.0.0 37a429ad12b4c9e6a62dbae4881a1ff03b81ab40 \
    a689d673abadf80f1efaf8ddaeee92d56fc2847b \
    d90ec67fdab9710f649a3c1d374fb6b938b9271a \
    8555789dd239a5ac229c1d9cee80b2a9f30b3bf7 \
    9a3552ca0d8b9aefb23ee1083c70c86c243e01af \
    1489f0f4cae3e9247a70e4003ab76bef45c5b986 \
    4e5d0fdf067c1f7116c22a2699d7a1941e536886
scripts/release/release.sh push

[limdor]

@philwo I see that a9419f38d5f29af31a6c8ebda09a6e0303a6ba54 did not made it in in the end. Any option to get it in case there is another rc?

[philwo]

@limdor Sorry :( This change wasn't mentioned here in this issue at all, thus I missed it in the end when compiling the list of cherry-picks. I'll do another rc4 with that cherry-pick now.

Everyone - for future cherry-picks, please add a comment on this issue, even if you told me just minutes ago somewhere else that it should get into 4.0. I can't keep track of all the things that are in flight in my head, so if it's not mentioned here explicitly, I will very probably miss it.

[philwo]

Building 4.0.0rc4 now:

scripts/release/release.sh create --force_rc=4 4.0.0 37a429ad12b4c9e6a62dbae4881a1ff03b81ab40 \
    a689d673abadf80f1efaf8ddaeee92d56fc2847b \
    d90ec67fdab9710f649a3c1d374fb6b938b9271a \
    8555789dd239a5ac229c1d9cee80b2a9f30b3bf7 \
    9a3552ca0d8b9aefb23ee1083c70c86c243e01af \
    1489f0f4cae3e9247a70e4003ab76bef45c5b986 \
    4e5d0fdf067c1f7116c22a2699d7a1941e536886 \
    a9419f38d5f29af31a6c8ebda09a6e0303a6ba54
scripts/release/release.sh push

[philwo]

Bazel 4.0.0rc4 postsubmit green: https://buildkite.com/bazel/bazel-bazel/builds/14846

Pushing the release candidate now.

[philsc]

@philwo , could we get 84fadcf81f81b2d7343ca4151a5639be7f2263ee cherry-picked? Thanks!

[konste]

@philwo if you are still not picky when it comes to cherry picks I would really like to see https://github.com/bazelbuild/bazel/commit/34d98234324da83e93ba0d5ef5702880d5ac7c5c (and https://github.com/bazelbuild/bazel/commit/079bb7d69931705bb2b092c9017090e224ef3043 to compliment it) cherry-picked. It fixes a nasty bogus warning which confuses our users.

[philwo]

@katre Could you advise how risky you judge https://github.com/bazelbuild/bazel/commit/84fadcf81f81b2d7343ca4151a5639be7f2263ee and https://github.com/bazelbuild/bazel/commit/34d98234324da83e93ba0d5ef5702880d5ac7c5c for cherry-picking?

Technically I could still do it today and then we can release 4.0 next Monday, but I don't know if the changes are too risky for this short time.

An alternative would be to get them into Bazel 4.1 (~mid January).

[katre]

84fadcf81f81b2d7343ca4151a5639be7f2263ee is safe: it's a small focused change and doesn't have a large effect.

34d98234324da83e93ba0d5ef5702880d5ac7c5c is harder: it's a larger change, and while all the tests pass it hasn't been widely used externally or internally, so I'm a bit worried about issues arising. I'd prefer to hold this back for a 4.1.

[konste]

Oh well, @katre is right. @philwo let's play safe and hold https://github.com/bazelbuild/bazel/commit/34d98234324da83e93ba0d5ef5702880d5ac7c5c for 4.1.

[konste]

I wonder what happened to --noincompatible_blacklisted_protos_requires_proto_info flag? We need this flag because we have to deal with rather old version of Protobuf. Now we tried Bazel 4.0 RC4 and it reports Unrecognized option: --noincompatible_blacklisted_protos_requires_proto_info I cannot find any mention that the flag is removed anywhere.

[comius]

I wonder what happened to --noincompatible_blacklisted_protos_requires_proto_info flag? We need this flag because we have to deal with rather old version of Protobuf. Now we tried Bazel 4.0 RC4 and it reports Unrecognized option: --noincompatible_blacklisted_protos_requires_proto_info I cannot find any mention that the flag is removed anywhere.

It has been removed in https://github.com/bazelbuild/bazel/pull/12431
I checked and it can still be reverted (imports need to be fixed).

[Yannic]

I wonder what happened to --noincompatible_blacklisted_protos_requires_proto_info flag? We need this flag because we have to deal with rather old version of Protobuf. Now we tried Bazel 4.0 RC4 and it reports Unrecognized option: --noincompatible_blacklisted_protos_requires_proto_info I cannot find any mention that the flag is removed anywhere.

That flag got removed in fe4a680b89415ec9e8c2a7ea26466f2f47b474e8. Feel free to revert that for 4.0.

[konste]

@philwo we need --noincompatible_blacklisted_protos_requires_proto_info removal reverted for 4.0 - it is show stopper for us. We hope to move to the newer Protobuf within a couple months and then we would not be needing that flag, but pulling it out right now is too early.

[philwo]

I just finished Bazel 4.0.0rc5... time for rc6. 😅

scripts/release/release.sh create --force_rc=5 4.0.0 37a429ad12b4c9e6a62dbae4881a1ff03b81ab40 \
    a689d673abadf80f1efaf8ddaeee92d56fc2847b \
    d90ec67fdab9710f649a3c1d374fb6b938b9271a \
    8555789dd239a5ac229c1d9cee80b2a9f30b3bf7 \
    9a3552ca0d8b9aefb23ee1083c70c86c243e01af \
    1489f0f4cae3e9247a70e4003ab76bef45c5b986 \
    4e5d0fdf067c1f7116c22a2699d7a1941e536886 \
    a9419f38d5f29af31a6c8ebda09a6e0303a6ba54 \
    84fadcf81f81b2d7343ca4151a5639be7f2263ee
scripts/release/release.sh push

[konste]

Well, it's a major release intended for the long term support - no wonder it needs a lot of ironing out to make sure it does not break anybody. Sorry for the extra work! On the other hand I am glad I have checked RC4 and discovered it.

[philwo]

@comius @Yannic what's the correct way to resolve this merge conflict in src/main/java/com/google/devtools/build/lib/rules/proto/ProtoLangToolchainRule.java?

import com.google.devtools.build.lib.analysis.BaseRuleClasses;
import com.google.devtools.build.lib.analysis.RuleDefinition;
import com.google.devtools.build.lib.analysis.RuleDefinitionEnvironment;
<<<<<<< HEAD
import com.google.devtools.build.lib.analysis.config.ExecutionTransitionFactory;
=======
import com.google.devtools.build.lib.analysis.config.HostTransition;
>>>>>>> fe4a680b89 (Remove --incompatible_blacklisted_protos_requires_proto_info)
import com.google.devtools.build.lib.packages.RuleClass;
import com.google.devtools.build.lib.packages.StarlarkProviderIdentifier;
import com.google.devtools.build.lib.packages.Type;

Looks like we only need ExecutionTransitionFactory and can remove HostTransition, right?

[konste]

I made a note for our team to jump on testing release candidates as soon as they appear. If we would test RC1 instead of RC4 it would be way less stressful for everybody. Is there a way to subscribe for notifications about the future RCs?

[Yannic]

@philwo I think you're right, only ExecutionTransitionFactory is needed. The conflict probably comes from 7acf9ea3fea4850d21114d84fbc5b663d105d3c7 (which should be in 4.0).

[comius]

Well, it's a major release intended for the long term support - no wonder it needs a lot of ironing out to make sure it does not break anybody. Sorry for the extra work! On the other hand I am glad I have checked RC4 and discovered it.

It's a LTS, so cherry-picking and fixing bugs after it is released should also be possible. Catching them now means less work later, but there's no need to try and catch all of them.

[philwo]

I tried yesterday, but I missed one important bit: We can't do reverts in a release branch at the moment. We can only do cherry-picks. 🤦

[philwo]

Let's see if we can manually override this...

scripts/release/release.sh create --force_rc=6 4.0.0 37a429ad12b4c9e6a62dbae4881a1ff03b81ab40 \
    a689d673abadf80f1efaf8ddaeee92d56fc2847b \
    d90ec67fdab9710f649a3c1d374fb6b938b9271a \
    8555789dd239a5ac229c1d9cee80b2a9f30b3bf7 \
    9a3552ca0d8b9aefb23ee1083c70c86c243e01af \
    1489f0f4cae3e9247a70e4003ab76bef45c5b986 \
    4e5d0fdf067c1f7116c22a2699d7a1941e536886 \
    a9419f38d5f29af31a6c8ebda09a6e0303a6ba54 \
    84fadcf81f81b2d7343ca4151a5639be7f2263ee
git revert fe4a680b89415ec9e8c2a7ea26466f2f47b474e8
scripts/release/release.sh push

[philwo]

Bazel 4.0.0rc6 postsubmit passed: https://buildkite.com/bazel/bazel-bazel/builds/14903

Binaries are here: http://releases.bazel.build/4.0.0/rc6/

[philwo]

I made a note for our team to jump on testing release candidates as soon as they appear. If we would test RC1 instead of RC4 it would be way less stressful for everybody. Is there a way to subscribe for notifications about the future RCs?

Thank you, testing the RCs is much appreciated and I understand it can be difficult!

We post announcements for release candidates to [email protected], e.g. the last one: https://groups.google.com/g/bazel-discuss/c/U5uzdYdeZqs

[scele]

Thanks for working on this release, lots of exciting features coming! :)
I tested 4.0.0rc4 today and filed https://github.com/bazelbuild/bazel/issues/12678.

[jbms]

It looks like it may be too late to cherry pick eb5cdcb972326321a649d9b4df495ae22aea3f12 (which addresses long-standing issue #7364 and adds support for env and env_inherit attributes to test rules), but it would be great to include it in 4.1 if possible (or 4.0 if still possible). Note that it requires bug fix e8835c1c221d76a2d5532d18083eaa04401619b3 to be cherry picked as well.

[konste]

I want to apologize upfront - I am very tired at the moment and may miss something obvious.
I try to use 4.0 RC6 on Linux (Ubuntu and CentOS) and get the error external/bazel_tools/tools/jdk/BUILD:485:6: Configurable attribute "actual" doesn't match this configuration: Could not find a JDK for host execution environment It points to this alias:

alias(
    name = "remote_jdk11",
    actual = select(
        {
            "//src/conditions:darwin": "@remotejdk11_macos//:jdk",
            "//src/conditions:windows": "@remotejdk11_win//:jdk",
            "//src/conditions:linux_aarch64": "@remotejdk11_linux_aarch64//:jdk",
            "//src/conditions:linux_x86_64": "@remotejdk11_linux//:jdk",
            "//src/conditions:linux_ppc64le": "@remotejdk11_linux_ppc64le//:jdk",
            "//src/conditions:linux_s390x": "@remotejdk11_linux_s390x//:jdk",
        },
        no_match_error = "Could not find a JDK for host execution environment, please explicitly" +
                         " provide one using `--host_javabase.`",
    ),

So it does not recognize that I run on linux_x86_64. I looked at //src/conditions and noticed that it changed. In 3.7.0 it looked like

config_setting(
    name = "linux_x86_64",
    values = {"cpu": "k8"},
    visibility = ["//visibility:public"],
)

and in 4.0 it changed to

config_setting(
    name = "linux_x86_64",
    constraint_values = [ "@platforms//os:linux", "@platforms//cpu:x86_64" ],
    visibility = ["//visibility:public"],
)

Could it be some --incompatible flag I am missing? I don't understand why 4.0 version of this config_setting is not recognized.

[comius]

I want to apologize upfront - I am very tired at the moment and may miss something obvious.

@konste This should work out of the box. I created an issue for this and let's move the discussion there https://github.com/bazelbuild/bazel/issues/12686

[sventiffe]

Heads up, I've moved the target date for the release to early January. With the current planning, we've been reaching a date too close to holiday season where we do not want to release new production binaries anymore (also, most of the team will be ooo end of year). This will give us the time to iron out the last issues. Please let me know if this change causes any problems for anyone.

[scele]

FYI I also had to cherry pick a87d7ed2411d5382bac58a20b79e09c464ad13b9 to make 4.0.0rc4 work for us.

[jbms]

With the target date delayed, is there still time to cherry pick support for env (see https://github.com/bazelbuild/bazel/issues/12455#issuecomment-742661373)?

[philsc]

If the delay means more time for cherry-picks I'd like to propose 3e969ff24a6a0e03139b9f288c88451a7dfa97cd.

[konste]

https://github.com/bazelbuild/bazel/issues/12686 is resolved.

[ulfjack]

I second the cherry-pick of a87d7ed. Without it, remote execution is broken. I can reproduce with a remote build of TensorFlow - shouldn't that be covered by CI?

[davido]

@ulfjack

Without it, remote execution is broken.

Gerrit tests are passing on RBE, using Bazel version 4.0.0rc6:

  $ bazel test --config=remote --remote_instance_name=<project-name> javatests/...

[AustinSchuh]

@ulfjack

Without it, remote execution is broken.

Gerrit tests are passing on RBE, using Bazel version 4.0.0rc6:

  $ bazel test --config=remote --remote_instance_name=<project-name> javatests/...

RBE must be handling the case differently. I'm seeing the following in the action log:

{
  "commandArgs": ["bazel-out/host/bin/external/bazel_tools/tools/build_defs/hash/sha256", "bazel-out/k8-opt/bin/external/base_image/image/004.tar.gz.nogz", "bazel-out/k8-opt/bin/external/base_image/image/004.tar.gz.nogz.sha256"],
  "environmentVariables": [{
    "name": "PATH",
    "value": "/bin:/usr/bin:/usr/local/bin"
  }],
  "platform": {
    "properties": [{
      "name": "OSFamily",
      "value": "Linux"
    }, {
      "name": "container-image",
      "value": "docker://artifactory.bluerivertech.com/dev-shasta-docker/engflow/re-ubuntu1804-bazel-java11@sha256:84ac43be6990a0b5e7a9d92f3d84474b8b2052c54f517a073b27cc531e5ec644"
    }, {
      "name": "dockerAddCapabilities",
      "value": "SYS_PTRACE"
    }, {
      "name": "dockerReuse",
      "value": "True"
    }]
  },
  "inputs": [{
    "path": "bazel-out/host/bin/external/bazel_tools/tools/build_defs/hash/sha256",
    "digest": {
      "hash": "ba91560f0c1126e77f4704acfdfab56583222f8af08b645e49bddcc7ca5453e7",
      "sizeBytes": "14987",
      "hashFunctionName": "SHA-256"
    }
  }, {
    "path": "/dev/null",
    "digest": {
      "hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
      "sizeBytes": "0",
      "hashFunctionName": "SHA-256"
    }
  }, {
    "path": "/dev/null",
    "digest": {
      "hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
      "sizeBytes": "0",
      "hashFunctionName": "SHA-256"
    }
  }, {
    "path": "/dev/null",
    "digest": {
      "hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
      "sizeBytes": "0",
      "hashFunctionName": "SHA-256"
    }

[meisterT]

I just tried to create a new RC with all cherry pick requests. There was a merge conflict (when merging https://github.com/bazelbuild/bazel/commit/eb5cdcb972326321a649d9b4df495ae22aea3f12) but I think I solved it successfully.

scripts/release/release.sh create --force_rc=7 4.0.0 e43825d0bef359f645e1cabf2164fd2db6ee4a35 082d58de852ebaa640bcf13cf419cbb94eec2b26 e8835c1c221d76a2d5532d18083eaa04401619b3 eb5cdcb972326321a649d9b4df495ae22aea3f12 a87d7ed2411d5382bac58a20b79e09c464ad13b9 3e969ff24a6a0e03139b9f288c88451a7dfa97cd

It's running through testing on BuildKite now: https://buildkite.com/bazel/bazel-bazel/builds/14950

[meisterT]

New RC is available here: http://releases.bazel.build/4.0.0/rc7/

Downstream testing kicked off: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1817

[divanorama]

rc7 says bazel version aka EMBED_LABEL is 3.7.0 (label is based on https://github.com/bazelbuild/bazel/blob/release-4.0.0rc7/CHANGELOG.md afaik)
bazel binary name is ok though - bazel-4.0.0rc7-$arch, so more of UI thing

[ulfjack]

@davido, I suspect it only affects actions that have an empty file as an input, so if you're not affected, that's great! I think Python runfiles may have a bunch of these empty files, but some other languages may as well.

Thanks, @meisterT, for the cherry-pick!

[martinxsliu]

@philwo If there is still time, could we cherry pick https://github.com/bazelbuild/bazel/commit/e6670825b1e183f81f5c864aafd425d512fa9ff5 as well? It fixes an issue with using the new --host_action_env flag. Thanks!

[AustinSchuh]

I'm guessing that the appetite for additional changes in 4.0 is small, but we've been running https://github.com/bazelbuild/bazel/commit/07400c0392e7be163f8a3396fa5cf89ce6705412 cherry-picked on 4.0-rc7 for a couple of weeks now with no issues and would appreciate a cherry-pick.

[jbms]

The previous commit that was cherry-picked, https://github.com/bazelbuild/bazel/commit/eb5cdcb972326321a649d9b4df495ae22aea3f12 unfortunately breaks the env attribute of container_image in rules_docker. The breakage is fixed by https://github.com/bazelbuild/bazel/commit/c83366064621d5a265eba14d93a03deff58fe6d8.

[alexeagle]

@comius thanks for that fix for jacoco runner. It no longer crashes, however I'm still not able to get coverage working with Bazel 4.0. I opened a separate issue to avoid spamming this release thread: https://github.com/bazelbuild/bazel/issues/12793

[comius]

Another cherry-pick 586069525d5a133ee23003b171a09fea496033cc, fixes #12793.

[meisterT]

Creating a new candidate with

scripts/release/release.sh create --force_rc=9 4.0.0 476b254c6d8c8fe0af9f48de442597f30dbdca54 e6670825b1e183f81f5c864aafd425d512fa9ff5 07400c0392e7be163f8a3396fa5cf89ce6705412 c83366064621d5a265eba14d93a03deff58fe6d8 586069525d5a133ee23003b171a09fea496033cc

Hopefully this will be the last one.

[meisterT]

Downstream pipeline is running here: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1853

https://releases.bazel.build/4.0.0/rc9/

[comius]

And another cherry-pick to fix coverage downstream 438dedd6483448a395026c55c22dac6bda24e669 :(

[meisterT]

It seems we also need to cherry pick 88b1cb4dabc5c448ebe6e1c7fb06249841de0a63 for some tensorflow issues,

[meisterT]

🤞

scripts/release/release.sh create --force_rc=10 4.0.0 6a60b30cd0f22d0ab84b2ddd658d5ccb899a8a76 438dedd6483448a395026c55c22dac6bda24e669 88b1cb4dabc5c448ebe6e1c7fb06249841de0a63

[meisterT]

I haven't heard of any outstanding issues and the release blocker list is empty, so in theory we should be good to release.

Since today's a Friday, I am reluctant to push the button just now, so we are aiming at a release on Monday.

[dmivankov]

Btw, does rc print correct version info in bazel version ? When I was compiling it locally it picked up 3.7.0 based on CHANGELOG.md text

[philwo]

@dmivankov I cannot reproduce that and the release candidate binaries built on our CI print the correct version number.

Note that the version number has to be explicitly embedded into the binary like this when building: https://github.com/bazelbuild/continuous-integration/blob/1a045ef8af19aade33ee932fcb87fd1a39cad2be/pipelines/bazel-release.yml#L70-L76

Usually when you compile it locally, it does not embed a version string.

[dmivankov]

Ok. manual EMBED_LABEL sounds ok to me, I guess I was getting it from
https://github.com/bazelbuild/bazel/blob/8346ea4cfdd9fbd170d51a528fee26f912dad2d5/compile.sh#L51
https://github.com/bazelbuild/bazel/blob/8346ea4cfdd9fbd170d51a528fee26f912dad2d5/scripts/bootstrap/buildenv.sh#L267

[meisterT]

We are preparing the release notes now in https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit?hl=en&forcehl=1#heading=h.44tbuy3ahiu1 - please have a look if you want to contribute.

[tschuett]

I couldn't find any hints about 4.0 being the first version with Long Term Support (LTS).

[limdor]

I couldn't find any hints about 4.0 being the first version with Long Term Support (LTS).

I added the comment in the doc to not get lost, good point. I would also be interested on that.
According to the announcement, I would expect to be LTS https://blog.bazel.build/2020/11/10/long-term-support-release.html

[philwo]

@tschuett Added, thanks for catching that. 😎

[philsc]

I'm guessing it's too late to cherry-pick the @platforms update (e03cb63e059420847d6578d7cbfe93f05615c95e)? The one packaged in rc10 is over a year old at this point.

[meisterT]

@philsc that was too late indeed - we may want to consider this for the next release of the 4.x release track.

[meisterT]

We have released: https://github.com/bazelbuild/bazel/releases/tag/4.0.0 :partying_face:

@vbatts @petemounce @excitoon please update your respective packages

[limdor]

Cool! Regarding the release bazel toolchains for 4.0, is it automatic or someone has to trigger it?
https://buildkite.com/bazel/bazel-toolchains

[philwo]

@smukherj1 Do we have to do anything to get bazel-toolchains 4.0 or is the process automated? 😊

[petemounce]

Published to chocolatey

[smukherj1]

@smukherj1 Do we have to do anything to get bazel-toolchains 4.0 or is the process automated? 😊

Some manual work involved. I'll take a look

[smukherj1]

@smukherj1 Do we have to do anything to get bazel-toolchains 4.0 or is the process automated? 😊

Some manual work involved. I'll take a look

@philwo unfortunately looks like this'll be delayed. #8380 broke the config generation pipeline and from the error it's not immediately obvious where the invalid escape sequence is coming from. Going to have to trace through a bunch of dependencies to figure it out :(