Closed lunaleaps closed 2 years ago
I believe these both need testing but in the continued effort to make the iOS build experience better, these two from @barbieri replace the current workarounds with what appear to be real solutions:
https://github.com/facebook/react-native/commit/a1c445a39c580037ada4a5d194a0d2daef15a25a https://github.com/facebook/react-native/commit/51bf55794899284e1c465d346a3f6ebd8a485da2
My only hesitation on those (other than "needs testing") is that I'm not sure of the implications with regard to transitive dependencies. Specifically:
__apply_Xcode_12_5_M1_post_install_workaround()
as it's not needed anymore, at least with recent versions of the dependencies, no patching is required with RCT-Folly" --> do we already transitively depend on "recent version" (and what are those minimum versions?)So I'm not sure if they fit (or can be made to fit) for a patch release or should wait for 0.67, but they have landed on main branch at least
request (fix ios release build via xcode) https://github.com/facebook/react-native/commit/cc59a7cbde1c0fc6d6ef059321d23bf287f08218
please revert facebook/react-native@1b0fb9b Related Discussion https://github.com/facebook/react-native/issues/31461 https://github.com/facebook/react-native/pull/28236#issuecomment-891730388
Android appearance module fix https://github.com/facebook/react-native/commit/25a2c608f790f42cbc4bb0a90fc06cc7bbbc9b95
please revert facebook/react-native@1b0fb9b Related Discussion facebook/react-native#31461 facebook/react-native#28236 (comment)
Has this been reverted on main?
Kotlin and Gradle bump maybe if possible, if not maybe in 0.67: https://github.com/facebook/react-native/commit/9ae3367431428748f5486c782199beb4f9c6b477
@svbutko I don't that will be included in 0.66.x. You can also upgrade gradle yourself.
@svbutko I don't that will be included in 0.66.x. You can also upgrade gradle yourself.
That's for the RN template, if it won't be in 0.66.x I mentioned that it would be fine to include it in 0.67
Kotlin and Gradle bump maybe if possible, if not maybe in 0.67: facebook/react-native@9ae3367
Just to note that I'm running those locally in 4 react-native 0.66 projects (two of which have big e2e harnesses, 2 of which are deployed on app stores) and they work fine as far as I can tell, no breaks seen when I moved on those
[edit to add that's just a success report, probably doesn't make sense for a patch release as it's not fixing a bug in react-native, per se]
Kotlin and Gradle bump maybe if possible, if not maybe in 0.67: facebook/react-native@9ae3367
Just to note that I'm running those locally in 4 react-native 0.66 projects (two of which have big e2e harnesses, 2 of which are deployed on app stores) and they work fine as far as I can tell, no breaks seen when I moved on those
[edit to add that's just a success report, probably doesn't make sense for a patch release as it's not fixing a bug in react-native, per se]
Same thing, I just wanted to note about since there's no 0.67 discussion yet
That PR (32398) hasn't landed (since you made it...2 hours ago :-) ) but I just looked and it looks great IMHO
@mikehardy it has been merged so i think we good to pick
@aliraza-noon indeed! @lunaleaps merged it in https://github.com/facebook/react-native/commit/d1a33cd139fab4565b1fc691f5751c4af99d5849 and since they own this issue I'll assume they know the pick, but I'm committing here to close the loop in this thread. :rocket:
Hey guys, sorry about the lack of responsiveness on this thread. I think my big question here has been, since we're planning on releasing 67 (cutting this week), and there are roughly a month of changes from 66 -> 67, should we just focus on getting 67 with these changes?
Are there any issues here that fundamentally break 0.66 usage? I think the strongest contenders are:
But these don't feel like major usage breakages for 0.66? True, the delta of changes between 0.66 and 0.67 may elongate release testing, I'm tempted to focus on releasing 67. Maybe if we see within a week that 67 has major release blockers, then I can start a patch release -- what do you guys think?
Pick and release, no rn release is ever fast and .0 releases have low adoption based on feedback. A point release is immediate and more trusted. 2 cents 😁
-- what do you guys think?
The Android appearance module fix https://github.com/facebook/react-native/commit/25a2c608f790f42cbc4bb0a90fc06cc7bbbc9b95 is a block for my app.
Okay sounds good, I can create a patch today. I've updated this issue with the picks I'm going to be taking which are all already on main
0.66.1 is out: https://www.npmjs.com/package/react-native
Let's have any 0.66.2 in this discussion: https://github.com/reactwg/react-native-releases/discussions/3
I guess I should say there is no such thing as a fast rn .0
release, quite evidently there are fast point releases! That was super quick. Thanks @lunaleaps
from 0.63.4 to 0.66.1,encounter this: ios/Pods/Headers/Public/RCT-Folly/folly/math.h:26:10: 'cmath' file not found ios/Pods/Headers/Public/React-Core/React/RCTConvert.h:17:9: Could not build module 'yoga'
Conversations on this thread are limited to 0.66 releases major issues and backport (cherry-pick) requests from commits that are already on master.
An example of a good such request is a bug fix for a serious issue that has been merged into master but did not make the 0.66.0 cut, with a link to the specific commit hash on main with the commit to cherry-pick, like this example link: facebook/react-native@bd2b7d6
In other words, if you cannot point to a particular commit on master, then your request likely belongs as a new issue in http://github.com/facebook/react-native/issues.
List of cherry picks
Local commits to backport to main
Requested but not sure if it should be done: