android build: Upgrade Gradle to 6.2. #4319
Conversation
|
(Linking the RN v0.63 upgrade issue, #4245.) |
chrisbobbe
force-pushed
the
pr-upgrade-gradle
branch
from
5c56010 to
33f34a5
Compare
Remember what we discovered at the last Gradle upgrade, at #4244 (comment):
I think in fact I can confirm that that's what we're seeing. Once you're already on 6.2, if you rerun that "upgrade" command with the exact same arguments -- so "upgrade again" to 6.2 -- then you get that gradlew.bat change. The same is true if you upgrade to some other version like 6.3. The other script change here, we actually get if you do the same with the version 6.0.1 we're already on. I'll add a commit that does the 6.0.1 re-upgrade, and amends the instructions-comment. |
…ure. The way we've historically managed this -- using the upgrade command in the most natural way -- has meant that we're always using the Gradle wrapper from the *previous* Gradle version we last upgraded from. The version mismatch itself is fine: much of the point of the Gradle wrapper is to be a thin indirection layer that can start up whatever version of Gradle a given project specifies. But when doing an upgrade, this behavior sure makes things confusing -- the shell script we end up with can vary when trying two different sequences of upgrades that end with the exact same version. That sure looks like something's wrong with the upgrade process, causing time spent debugging. Now that we have debugged it, there's a simple workaround to make it stop happening: just run each upgrade twice, so that everything settles at the new version. Do that for the last upgrade, and update the comment so we know to do that in the future.
Part of the RN v0.62 -> v0.63 changes to the template app [1], corresponding to the following commits: - facebook/react-native@aa0ef1533 - facebook/react-native@a89a55353 - facebook/react-native@947a5593e - facebook/react-native@d4d8887b5 The build scan revealed a handful of new deprecation notices not flagged at our last Gradle upgrade (2c42511), also for things that will be removed in Gradle 7.0 [2]. [greg: updated jar too, by following new upgrade procedure described in preceding commit] [1] https://react-native-community.github.io/upgrade-helper/?from=0.62.2&to=0.63.3 [2] https://scans.gradle.com/s/3ocxcu7uxryfe/deprecations
Relative to 6.2, this just fixes some bugs: https://docs.gradle.org/6.2.1/release-notes.html#fixed-issues https://docs.gradle.org/6.2.2/release-notes.html#fixed-issues
gnprice
force-pushed
the
pr-upgrade-gradle
branch
from
33f34a5 to
04624e0
Compare
|
Merged, thanks! I also bumped it further to the latest bugfix release of that 6.2.x series. |
Ohh, OK, right! That first commit, with the instruction to run the same command twice, is helpful. I remembered there was some oddness about how these upgrades worked, but I was fuzzy on the details; I should have looked back at your comments on the previous upgrade. Thanks for the reminder, and for fixing it for the future. 🙂 |
Part of the RN v0.62 -> v0.63 changes to the template app [1],
corresponding to the following commits:
I didn't find that the additions to android/gradlew.bat (from
facebook/react-native@d4d8887b5) were reproducible using our upgrade
command for any upgrade between 6.0.1 (where we were before this
commit) and 6.2.
But I could reproduce them by running that command to upgrade to
6.3. So, we might as well include them. It's possible that there are
some difference between the upgrade command we run and the command
React Native maintainers run, or (maybe more likely) React Native
initially went for an upgrade to 6.3 then partially backed it out,
to only go to 6.2.
The build scan revealed a handful of new deprecation notices not
flagged at our last Gradle upgrade (2c42511), also for things that
will be removed in Gradle 7.0 [2].
[1] https://react-native-community.github.io/upgrade-helper/?from=0.62.2&to=0.63.3
[2] https://scans.gradle.com/s/3ocxcu7uxryfe/deprecations