Release 1.0 - September 2019 #8573

dslomov · 2019-06-06T08:38:55Z

Target RC date - September 3rd, 2019.
See the blog post for some details

kkiningh · 2019-06-06T19:50:27Z

There's quite a few issues with the 1.0 tag left, including some that seem fairly significant. Which ones does the Bazel team still expect to address before the release?

dslomov · 2019-06-07T13:03:37Z

There's quite a few issues with the 1.0 tag left, including some that seem fairly significant. Which ones does the Bazel team still expect to address before the release?

We will do a review of those. If you think a specific issue is particularly important to address for 1.0, please comment on it.

katre · 2019-08-02T19:05:12Z

Note that aaff22c and 7ed66f7 are rollbacks of commits that are present in 0.29.0. They should be rolled forward again before 1.0 is cut, but we need to make sure of that when choosing the baseline.

(They were rolled back due to an internal issue that does not affect Bazel. See http://b/138789815 for the internal discussion.)

cgruber · 2019-08-03T02:51:36Z

In particular, both early phases of the rules_kotlin and rules_android roadmaps seem not to have any indications of their progress, and I have had several assurances that their "mid-2019" goals would roll out as a part of the Bazel 1.0 process. Can someone please confirm this, or otherwise inform folks who are waiting on those?

dslomov · 2019-09-02T11:23:42Z

Current list of blockers is https://github.com/bazelbuild/bazel/labels/bazel%201.0

dslomov · 2019-09-05T10:03:27Z

97a8264 is a 1.0 baseline I am going to try. Failing downstream projects:

TensorFlow: incompatible_remove_legacy_whole_archive: Remove --legacy_whole_archive while setting default to false #7362 (comment)
- Need fixes from TensorFlow
rules_foreign_cc: Add support for libtool over ar bazel-contrib/rules_foreign_cc#309
- Need fix from rules_foreign_cc
rules_typescript: fix in flight
rules_nodejs: rules_nodejs/.bazelci/presubmit.yml was changed, a wrong target was added but the following fixes didn’t get in because the pipeline was red for some other reason. Filed Rules_nodejs failing on Bazel CI bazel-contrib/rules_nodejs#1096

dslomov · 2019-09-05T12:39:46Z

Stuck on bazelbuild/continuous-integration#810, will retry the build once that goes in.

dslomov · 2019-09-06T12:06:58Z

Cherry-picking a0e3bb2 - fix for #9327

dslomov · 2019-09-06T12:11:36Z

 ./scripts/release/release.sh create --force_rc=2 1.0.0 97a8264 a0e3bb2

katre · 2019-09-06T13:46:59Z

I also cherrypicked 5c02b92 into 0.29.1, is that in 1.0.0?

dslomov · 2019-09-06T14:06:48Z

I also cherrypicked 5c02b92 into 0.29.1, is that in 1.0.0?

I believe so.

dslomov · 2019-09-09T09:11:59Z

1.0.0rc2 is available: https://releases.bazel.build/1.0.0/rc2/index.html
Downstream projects: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1183.
Failures:

davido · 2019-09-09T14:30:26Z

It seems, that 1.0.0rc2 broke Gerrit (stable-2.14 release):

  ERROR: /home/jenkins/workspace/Gerrit-verifier-bazel/gerrit/gerrit-extension-api/BUILD:63:1: in java_doc rule //gerrit-extension-api:extension-api-javadoc: 
Traceback (most recent call last):
	File "/home/jenkins/workspace/Gerrit-verifier-bazel/gerrit/gerrit-extension-api/BUILD", line 63
		java_doc(name = 'extension-api-javadoc')
	File "/home/jenkins/workspace/Gerrit-verifier-bazel/gerrit/tools/bzl/javadoc.bzl", line 20, in _impl
		depset(transitive = [j.java.transitive_...])
	File "/home/jenkins/workspace/Gerrit-verifier-bazel/gerrit/tools/bzl/javadoc.bzl", line 20, in depset
		j.java.transitive_deps
object of type 'JavaSkylarkApiProvider' has no field 'transitive_deps'

It seems to be related to: [1]. This is the place in the code: [2]. This is the complete CI log: [3].

All is fine on 0.29.0 release.

[1] #7598
[2] https://github.com/GerritCodeReview/gerrit/blob/stable-2.14/tools/bzl/javadoc.bzl#L20-L21
[3] https://gerrit-ci.gerritforge.com/job/Gerrit-verifier-bazel/71542/consoleText

dslomov · 2019-09-10T10:57:06Z

It seems, that 1.0.0rc2 broke Gerrit (stable-2.14 release):
  ERROR: /home/jenkins/workspace/Gerrit-verifier-bazel/gerrit/gerrit-extension-api/BUILD:63:1: in java_doc rule //gerrit-extension-api:extension-api-javadoc: 
Traceback (most recent call last):
	File "/home/jenkins/workspace/Gerrit-verifier-bazel/gerrit/gerrit-extension-api/BUILD", line 63
		java_doc(name = 'extension-api-javadoc')
	File "/home/jenkins/workspace/Gerrit-verifier-bazel/gerrit/tools/bzl/javadoc.bzl", line 20, in _impl
		depset(transitive = [j.java.transitive_...])
	File "/home/jenkins/workspace/Gerrit-verifier-bazel/gerrit/tools/bzl/javadoc.bzl", line 20, in depset
		j.java.transitive_deps
object of type 'JavaSkylarkApiProvider' has no field 'transitive_deps'
It seems to be related to: [1]. This is the place in the code: [2]. This is the complete CI log: [3].

All is fine on 0.29.0 release.

[1] #7598
[2] https://github.com/GerritCodeReview/gerrit/blob/stable-2.14/tools/bzl/javadoc.bzl#L20-L21
[3] https://gerrit-ci.gerritforge.com/job/Gerrit-verifier-bazel/71542/consoleText

Well, yes #7598 is a breaking change in 1.0 (marked as such). Use j[JavaInfo].transitive_deps instead (per backwards compatibility policy and Updating Bazel guidance.

davido · 2019-09-12T19:57:06Z

I would like to bring to your attention the fact, that 1.0.0rc2 broke IntelliJ plugin. I just wrote this issue.

kastiglione · 2019-09-13T15:41:33Z

Hi, can this commit be picked into 1.0: #9371?

On macOS, it affects hermeticity and caching.

jin · 2019-09-13T17:17:09Z

@davido Looks like the fix is in (bazelbuild/intellij@5f03bde), and the plugin version with that fix is expected to be released early next week.

dslomov · 2019-09-16T08:50:55Z

Will cherrypick ada2c55

dslomov · 2019-09-16T08:52:24Z

rc3:

./scripts/release/release.sh create --force_rc=3 1.0.0 97a8264 a0e3bb2 ada2c55

DavidGoldman · 2019-09-18T16:17:07Z

We'll also want to cherry pick #9403 as it helps improving cache hit rates across multiple macOS versions

dslomov · 2019-09-19T01:01:16Z

Could you explain in more detail which problem #9403 fixes and why it warrants cherry-picking as opposed to waiting for the next release? Is it a serious regression?

DavidGoldman · 2019-09-19T13:44:30Z

Could you explain in more detail which problem #9403 fixes and why it warrants cherry-picking as opposed to waiting for the next release? Is it a serious regression?

It's not a serious regression but a nice to have given that the issue is caused by having developers on different macOS versions and a new version of macOS will drop next month.

dslomov · 2019-09-19T15:41:20Z

Could you explain in more detail which problem #9403 fixes and why it warrants cherry-picking as opposed to waiting for the next release? Is it a serious regression?

It's not a serious regression but a nice to have given that the issue is caused by having developers on different macOS versions and a new version of macOS will drop next month.

I say we get in 1.1 then.

kastiglione · 2019-09-19T16:28:22Z

It means developers on 10.14 and 10.15 will share very little cache. Anything that has wrapped_clang (for example) as an input, will not share cache with the exact same build built for 10.14 vs 10.15, even if Xcode and all other dependencies are identical.

davido · 2019-09-25T07:18:37Z

I've tested all major use cases with building and testing of Gerrit project with the latest rc3, and it works as expected. I can build and test Gerrit on JDK 8/11 with embedded_jdk11, and on JDK 13 with toolchain_vanilla and that is great!

I've only detected two minor issues. One regression hard coded vanilla_toolchain to produce byte code major version 52 (Java 8) and one bug that wasn't discovered until now, where current_host_java_runtime is not provided in runfiles directory.

There are pending PRs for review for both problems: 1, 2, and we applied workarounds in Gerrit already: a, b.

It would be great, if those fixes could make it in 1.0 release, but they can also be fixed in 1.1 (or later).

wesleyw72 · 2019-09-25T20:02:17Z

#9439

dslomov · 2019-09-27T17:52:00Z

#9415 is a release blocker, will cherry-pic a fix.
Still waiting for decision on #9270.

dslomov · 2019-09-30T13:52:44Z

rc4:

 ./scripts/release/release.sh create --force_rc=4 1.0.0 97a8264 a0e3bb2 ada2c55 847df72

dslomov · 2019-10-01T09:49:24Z

rc4 test run: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1216

dslomov · 2019-10-01T12:47:41Z

The run is green!

iirina · 2019-10-02T08:08:07Z

@dslomov Please cherry pick 5cfa030 which fixes the performance regression described in #9270.

dslomov · 2019-10-02T08:27:38Z

rc5: ./scripts/release/release.sh create --force_rc=5 1.0.0 97a8264 a0e3bb2 ada2c55 847df72 5cfa030

dslomov · 2019-10-02T08:50:49Z

rc5 test run: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/1218

davido · 2019-10-03T10:04:11Z

It tuns out, that this build spam issue that was reported multiple times already: [1], [2] is actually a regression from remote JDK upgrade to JDK 11 in this commit. See also my detailed analysis of the problem.

After trying to drop Java language level 7 compatibility in Bazel: [3] and Protobuf: [4] projects that was rejected upstream I figured that we can avoid passing mutually exclusive options to Java compiler in non-invasive way, by extending existing ReleaseOptionNormalizer in JavacOptions, in: [5].

Can we consider to apply the fix in java_tools, build new java_tools version 5.2 and cherry-pick it here?

Or, alternatively, could we do official release of java_tools with: [5] merged, but without upgrading Bazel, so that Gerrit project could switch to consuming new java_tools version and that would fix the console spamming issue for Gerrit project.

[1] #8772
[2] https://bugs.chromium.org/p/gerrit/issues/detail?id=11102
[3] #9450
[4] protocolbuffers/protobuf#6711
[5] #9494

dslomov · 2019-10-07T20:57:56Z

Or, alternatively, could we do official release of java_tools with: [5] merged, but without upgrading Bazel, so that Gerrit project could switch to consuming new java_tools version and that would fix the console spamming issue for Gerrit project.

I like this option. @iirina wdyt?

[1] #8772
[2] https://bugs.chromium.org/p/gerrit/issues/detail?id=11102
[3] #9450
[4] protocolbuffers/protobuf#6711
[5] #9494

iirina · 2019-10-08T08:46:08Z

I agree, I don't think we should block the release. Submitting [5] and releasing java_tools sounds reasonable to me. You can follow the java_tools release at bazelbuild/java_tools#17

dslomov · 2019-10-10T09:53:00Z

Will release rc5 today.

gertvdijk · 2019-10-10T11:13:32Z

Will release rc5 today.

Uhm, I noticed 1.0.0 was just released? https://github.com/bazelbuild/bazel/releases/tag/1.0.0

edit: oh, "1.0.0rc5 as 1.0.0" I guess 😄 🎉

dslomov · 2019-10-10T11:39:38Z

Published 1.0.0rc5 as 1.0.0.

Pinging package maintainers: @vbatts @petemounce @excitoon

zegl · 2019-10-10T12:20:32Z

Congratulations on the 1.0 release, this is a huge milestone for the entire community! 🥇

vbatts · 2019-10-10T12:25:46Z

Right on, but is there still no solid response for building on aarch64? I am getting increased requests there, but have not gotten it built yet

…

-------- Original Message --------

On Oct 10, 2019, 07:40, Dmitry Lomov wrote: Published 1.0.0rc5 as 1.0.0. - https://github.com/bazelbuild/bazel/releases/tag/1.0.0 - https://releases.bazel.build/1.0.0/release/index.html Pinging package maintainers: ***@***.***(https://github.com/vbatts) ***@***.***(https://github.com/petemounce) ***@***.***(https://github.com/excitoon) — You are receiving this because you were mentioned. Reply to this email directly, [view it on GitHub](#8573?email_source=notifications&email_token=AAAQL2M3IM7MYXXEVGHER43QN4ICJA5CNFSM4HU6O4R2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEA35SVA#issuecomment-540531028), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAAQL2NMW2ILKQU6C4JIJHDQN4ICJANCNFSM4HU6O4RQ).

vbatts · 2019-10-10T13:08:06Z

until then, builds kicked off for centos, rhel, and fedora https://copr.fedorainfracloud.org/coprs/build/1052142

keith · 2019-10-10T22:41:10Z

If there is going to be a patch release I believe #9376 should be cherry picked which fixes this remote cache regression from 0.29.0 #9362

petemounce · 2019-10-12T13:28:28Z

Published to chocolatey, apologies for delay.

jmillikin-stripe · 2019-10-16T04:49:10Z

#9998 is an unexpected regression from v0.29, given that str.replace() is documented as taking a keyword parameter for maxsplit and major projects such as Kubernetes depend on the documented behavior.

dslomov added the release label Jun 6, 2019

dslomov pinned this issue Jun 7, 2019

dslomov unpinned this issue Jun 7, 2019

kkiningh mentioned this issue Jun 7, 2019

CPP gdb lldb no debugging symbols found #2537

Open

dslomov self-assigned this Jul 1, 2019

meisterT mentioned this issue Jul 15, 2019

Bazel 1.0 release date ? #8886

Closed

cphang99 mentioned this issue Aug 30, 2019

Introduce flag to conditionally disable BES artifact upload #9031

Closed

dslomov pinned this issue Sep 2, 2019

dslomov mentioned this issue Sep 6, 2019

[Security] netrc support passes original credentials on HTTP redirects #9327

Closed

laurentlb mentioned this issue Sep 9, 2019

Bazel 1.0.0rc2 broke Gerrit (stable-2.14 release) #9353

Closed

seanpmorgan mentioned this issue Sep 10, 2019

Utilize Bazel 1.0 during build tensorflow/addons#498

Closed

This was referenced Sep 27, 2019

Bazel performance regression caused by b321444 #9270

Closed

Default java toolchain changed to target java 8 and broke toolchain_vanilla #9415

Closed

dslomov closed this as completed Oct 11, 2019

meisterT unpinned this issue Nov 6, 2019

Release 1.0 - September 2019 #8573

Release 1.0 - September 2019 #8573

Comments

dslomov commented Jun 6, 2019 • edited Loading

kkiningh commented Jun 6, 2019

dslomov commented Jun 7, 2019

katre commented Aug 2, 2019

cgruber commented Aug 3, 2019

dslomov commented Sep 2, 2019

dslomov commented Sep 5, 2019 • edited by meteorcloudy Loading

dslomov commented Sep 5, 2019

dslomov commented Sep 6, 2019

dslomov commented Sep 6, 2019

katre commented Sep 6, 2019

dslomov commented Sep 6, 2019

dslomov commented Sep 9, 2019

davido commented Sep 9, 2019 • edited Loading

dslomov commented Sep 10, 2019

davido commented Sep 12, 2019

kastiglione commented Sep 13, 2019

jin commented Sep 13, 2019

dslomov commented Sep 16, 2019

dslomov commented Sep 16, 2019

DavidGoldman commented Sep 18, 2019

dslomov commented Sep 19, 2019

DavidGoldman commented Sep 19, 2019

dslomov commented Sep 19, 2019

kastiglione commented Sep 19, 2019 • edited Loading

davido commented Sep 25, 2019 • edited Loading

wesleyw72 commented Sep 25, 2019

dslomov commented Sep 27, 2019

dslomov commented Sep 30, 2019

dslomov commented Oct 1, 2019

dslomov commented Oct 1, 2019

iirina commented Oct 2, 2019

dslomov commented Oct 2, 2019

dslomov commented Oct 2, 2019

davido commented Oct 3, 2019

dslomov commented Oct 7, 2019

iirina commented Oct 8, 2019

dslomov commented Oct 10, 2019

gertvdijk commented Oct 10, 2019 • edited Loading

dslomov commented Oct 10, 2019

zegl commented Oct 10, 2019

vbatts commented Oct 10, 2019 via email

vbatts commented Oct 10, 2019

keith commented Oct 10, 2019

petemounce commented Oct 12, 2019

jmillikin-stripe commented Oct 16, 2019

dslomov commented Jun 6, 2019 •

edited

Loading

dslomov commented Sep 5, 2019 •

edited by meteorcloudy

Loading

davido commented Sep 9, 2019 •

edited

Loading

kastiglione commented Sep 19, 2019 •

edited

Loading

davido commented Sep 25, 2019 •

edited

Loading

gertvdijk commented Oct 10, 2019 •

edited

Loading