-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bump error prone version to 2.4.0 #11426
Bump error prone version to 2.4.0 #11426
Conversation
9a88ef6
to
2959c1f
Compare
@jin @meteorcloudy Question about Guava upgrade to sync with the version used in Error Prone. It appears that the version is used in https://maven.google.com/com/android/tools/sdklib/27.1.0-alpha09/sdklib-27.1.0-alpha09.jar Are there any plans to bump the sdklib ? All Andoird tests are failing now:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any way we can do this to a version that does not have SNAPSHOT in the name. A fixed version like is 2.3.4 preferable.
Please see #10394 (comment) The fastest way to update android_common is actually to patch it. Fully upgrading the JAR will take weeks/months to finish due to internal blockers. cc @ahumesky |
I am not a big friend of patching third party dependencies... Weeks or months to upgrade major external dependency is fine for such complex project as Bazel. Check Jetty upgrade in GWT: it took me years and dozen of transitive dependencies must be updated: [1]. Can you comment what has to be done to bump |
This is still waiting for Error Prone project to review my PR to fix this issue, where I demoted two checks to warning severity and SNPASHOT release that I am upgrading here, is included that PR. In that way the upgrade to newer Error Prone release is not breaking any more, and we don't have to protect it with Upgrade of Error Prone to a non SNAPSHOT release is in another PR that is pending for review. Though it will break all Bazel users who rely on cross compilation. I fixed two breakages in rules_closure and rules_kotlin, but there would be definitely more breakages in the wild. |
The open issues have been fixed / have pending fixes, I will cut a non-SNAPSHOT Error Prone release once Bazel's CI is clean with Error Prone at head. |
@cushon Since google/error-prone@b81bf44, EP is using shaded
However, Bazel is still using dedicated artifacts for the transitive dependencies of the above libraries. Moreover, Moreover, yet another new dependency was added to EP 2.3.5: ´ |
2959c1f
to
2f2f25b
Compare
a20a9e6
to
870a19b
Compare
It's now the case (after downgrading Guava again not to conflict with Android SDK): Bazel CI is clean with Error Prone at head. After demoting of problematic bug pattern to severity level warning, there is no known backwards compatibility issues. When 2.4.0 is released, I will update that PR and replace 2.3.5-SNAPSHOT jars with 2.4.0 jars. |
@aiuto Can you please update the reviewer list? team-Android can be removed now, because after Guava library downgrade there is no conflicts any more as can be seen that the CI is green, Yay! As pointed out by @philwo in Release 3.2 issue:
@lberki Who supposed to review/merge this PR and as the follow-up conduct new As you might know, the upcoming Error Prone 2.4.0: [2] fixed many bugs, added new checks, demoted backwards incompatible checks to warnings severity level only (thanks @cushon!) and added support for current JDK 14. [1] https://github.com/davido/java_tools/releases/tag/v14.0 |
If tests pass and @cushon says this is fine to merge, it's LGTM from my side. Do I understand the last comment that we have to wait for Error Prone |
Yes, exactly. We are still waiting here until
Once, EP 2.4.0 is released, I will replace the JARs in this PR and will mark this PR as "ready for review" (it's currently draft). However, even if this PR is merged, we still need to conduct new |
I'll figure out how to do it, when we're at that step in the process. :) |
The future could be faster than you think, if @cushon will release EP 2.4.0 in the next days, and I will update this PR couple of hours later, and you would merge the new version of this PR ASAP, then we would be at that step in the process, so may be you can launch the second stage of the rocket already now? ;-) |
@davido Error Prone 2.4.0 is ready to go |
One test seems to be failing on Mac Os X. All is fine here on Linux:
|
Fixes bazelbuild#11272 (first attempt that was reverted: bazelbuild#9286).
Fixes: bazelbuild#11272. This change updates error prone to 2.3.5 SNAPSHOT and includes demotion of breaking changes to warning severity: ExtendsAutoValue and RefersToDaggerCodegen. Given that Bazel EP integration does not activate warning checks, this upgrade is backwards compatible and must not be protected with new --incompatible_use_error_prone_2.3.5_version option. Additional library is needed: threeten-extra-1.5.0.
351c143
to
d6a3566
Compare
I have rebased the whole series on top of master, let's see if it helps with failing @meteorcloudy @laurentlb Can you shed some light why |
@davido That test is flaky and it’s deactivated at head. By rebasing your PR should now also have picked up the commit that disables the test. 👍 |
Is this blocked on anything, or can we merge it? |
It would be great if this could be merged. The follow-up work, e.g. adding native support for JDK 14 toolchain depends on new Error Prone version. |
@philwo , are there any blockers left? |
Sorry, the only remaining blocker was finding time on my side :( I'll get to this tomorrow, promise! |
@philwo Thanks. It would be great, to ship new verson of That means, however, that only merging this PR doesn't help much. What must happen as follow-up is to conduct new |
@davido Yes, no problem. 👍 I'll do this and ensure that it's all done in time for the next release cut :) |
I have verified all sha256sums of the JARs added in this PR against freshly downloaded copies from Maven:
Merging this now. |
Merged in 239b2aa. |
Thanks @philwo! Can we start the next step and kick off |
No description provided.