Release 0.22 - January 2019

[laurentlb]

Target RC date: January 7th

[aehlig]

Looking at the nightly CI run, we can use deb028e as a clean base line.

[aehlig]

`scripts/release/release.sh create 0.22.0 deb028e`

…

-- Klaus Aehlig Google Germany GmbH, Erika-Mann-Str. 33, 80636 Muenchen Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschaeftsfuehrer: Paul Terence Manicle, Halimah DeLaine Prado

[aehlig]

RC1 available at https://releases.bazel.build/0.22.0/rc1/index.html

[meteorcloudy]

I thought a3a5975 could make it into 0.22, but it didn't. So we need cherry pick it to fix #6890

[aehlig]

`scripts/release/release.sh create --force_rc=2 0.22.0 deb028e a3a5975`

…

-- Klaus Aehlig Google Germany GmbH, Erika-Mann-Str. 33, 80636 Muenchen Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschaeftsfuehrer: Paul Terence Manicle, Halimah DeLaine Prado

[aehlig]

RC2 is available at https://releases.bazel.build/0.22.0/rc2/index.html

[keith]

I believe that this file should be included in 0.22 otherwise the migration window for the new CcInfo provider #7036 doesn't really include 0.22. Also if you're using this API currently, you'll have to use --noincompatible_disable_legacy_cc_provider in production until 0.23 is released.

[aehlig]

I believe that this file should be included in 0.22 otherwise the migration window for the new CcInfo provider #7036 doesn't really include 0.22.

Since 3976d58 was committed after the cut-off date, our policy is to delay the migration window rather than to cherry-pick. I.e., #7036 would have use 0.23 as migration window and cannot flip the flag before 0.24.

[jmillikin]

I'm seeing a Bazel crash from a java.lang.IllegalStateException when using the new C++ toolchains: #7136

[aehlig]

I'm seeing a Bazel crash from a java.lang.IllegalStateException when using the new C++ toolchains: #7136

Do I understand correctly that this just means that the new C++ toolchains are not ready yet (hence, we probably have to postpone the migration window). Or does anything break that works on bazel 0.21?

[jmillikin]

My code is newly written for the v0.22 toolchains. I expect code written to the existing API would work properly.

[lberki]

@aehlig : can we add the following two flags to the "0.22 is the migration window for these flags" list?

--incompatible_disable_legacy_proto_provider
--incompatible_disable_proto_source_root

[lberki]

Tracking bug for --incompatible_disable_legacy_proto_provider: #7152

[lberki]

Tracking bug for --incompatible_disable_proto_source_root: #7153

[aehlig]

Thanks. Will add this to the release announcement.

[dslomov]

I believe that this file should be included in 0.22 otherwise the migration window for the new CcInfo provider #7036 doesn't really include 0.22.

Since 3976d58 was committed after the cut-off date, our policy is to delay the migration window rather than to cherry-pick. I.e., #7036 would have use 0.23 as migration window and cannot flip the flag before 0.24.

See #7036 (comment) - the shim file is not really necessary for migration and only served as an example (in fact, it was removed from Bazel distribution)

[dslomov]

@aehlig : can we add the following two flags to the "0.22 is the migration window for these flags" list?

--incompatible_disable_legacy_proto_provider
--incompatible_disable_proto_source_root

Suggestion: let's not list the individual migration window incompatible flags in the release announcement, instead let's only publish a link to issues with migration-0.22 label
We should still list all breaking changes that have actually occurred in 0.22 in the release annoucement.

WDYT?

[aehlig]

Suggestion: let's not list the individual migration window incompatible flags in the release announcement, instead let's only publish a link to issues with migration-0.22 label
[...]

WDYT?

I think that, if by the time of the release announcement, we cannot tell the users which migrations could/should be done, we cannot reasonably except them to act in this migration window. So there is some value in committing to saying which migrations we believe are ready—and in this way ensure there is no surprise of a retroactively added label saying "you should have migrated during the last releas".

[buchgr]

We'll unfortunately need to rollback the --incompatible_strict_action_env flag flip from the 0.21 release (See #7026). Also, we'll need to cherry-pick #7174 which fixes a bug that introduces flakyness on our CI. I ll post the commits later today.

[philwo]

We kindly ask for the following cherry-picks:

• b8d0e1b
• 3759e38
• 4473bb1
• 9137fb9

[dslomov]

Suggestion: let's not list the individual migration window incompatible flags in the release announcement, instead let's only publish a link to issues with migration-0.22 label
[...]
WDYT?

I think that, if by the time of the release announcement, we cannot tell the users which migrations could/should be done, we cannot reasonably except them to act in this migration window. So there is some value in committing to saying which migrations we believe are ready—and in this way ensure there is no surprise of a retroactively added label saying "you should have migrated during the last releas".

Of course, we will never add migrations after release is published (only the release manager should add migration-X.Y labels, and never do so after the release is out). But we might remove migrations where things didn't pan out (because the bugs are discovered or whatnot)

[dslomov]

We kindly ask for the following cherry-picks:

• b8d0e1b
• 3759e38
• 4473bb1
• 9137fb9

I can haz justification? :)
Could you specify (briefly!), for the benefit of release manager, which commit fixes which issue (and, unless this is already discussed in the issue, why that issue is a blocker). Thanks!

[aehlig]

`scripts/release/release.sh create --force_rc=3 0.22.0 deb028e a3a5975 b8d0e1b 3759e38 4473bb1 9137fb9`

…

-- Klaus Aehlig Google Germany GmbH, Erika-Mann-Str. 33, 80636 Muenchen Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschaeftsfuehrer: Paul Terence Manicle, Halimah DeLaine Prado

[aehlig]

rc3 available at https://releases.bazel.build/0.22.0/rc3/index.html

[petemounce]

RCs 1-3 pushed to chocolatey.

[buchgr]

Unfortunately #7212 is a regression. I am rolling back the root cause of it: #7216

[aehlig]

Unfortunately #7212 is a regression. I am rolling back the root cause of it: #7216

OK, so I'll wait till #7216 is committed and generate a new RC then, with that commit added as cherry-pick.

[philwo]

@dslomov Absolutely! Will do so in the future.

b8d0e1b

Only affects the release scripts and was required because the name of a key used to decrypt the GitHub token that we use to upload the release to GitHub changed. Without this commit, the release script would crash when trying to upload the files to GitHub. The change doesn't affect Bazel itself.

3759e38

Fixes #7174, #7160 and #4751. There was a long-standing issue in Bazel that caused builds and tests to randomly fail with an IOException on CI and possibly for other users, too. The problems became worse recently due to other code changes that tripped over the race condition, so expediting this fix was important.

4473bb1

Fixes #6860, which caused CI jobs on Windows to fail when any test was flaky, due to a race condition in the process management code that prevented Bazel from cleaning up test output files.

9137fb9

Reverts an incompatible flag flip that broke users of Bazel 0.21.0 (but discussing and analyzing the cause and what a good way to fix it took time, so the revert wasn't ready yet when the baseline for 0.22.0 was cut).

[aehlig]

OK, so I'll wait till #7216 is committed and generate a new RC then, with that commit added as cherry-pick.

The relevant changes to cherry-pick are 12ab12e and 6345c74. Will create a new RC soon.

[aehlig]

`scripts/release/release.sh create --force_rc=4 deb028e a3a5975 b8d0e1b 3759e38 4473bb1 9137fb9 12ab12e 6345c74`

…

-- Klaus Aehlig Google Germany GmbH, Erika-Mann-Str. 33, 80636 Muenchen Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschaeftsfuehrer: Paul Terence Manicle, Halimah DeLaine Prado

[aehlig]

Sorry, that, of course, should read

scripts/release/release.sh create --force_rc=4 0.22.0 deb028e a3a5975 b8d0e1b 3759e38 4473bb1 9137fb9 12ab12e 6345c74

[aehlig]

RC4 is available at https://releases.bazel.build/0.22.0/rc4/index.html

[aehlig]

As no more issues were reported, will promote rc4 to release.

[aehlig]

Released, see https://github.com/bazelbuild/bazel/releases/tag/0.22.0

[petemounce]

Pushed to chocolatey

[davido]

Bazel 0.22.0 Alpine Linux package is here.