-
Notifications
You must be signed in to change notification settings - Fork 404
Potential v0.66.1 Patch Release #254
Comments
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: facebook/react-native@a1c445a My only hesitation on those (other than "needs testing") is that I'm not sure of the implications with regard to transitive dependencies. Specifically:
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) |
please revert facebook/react-native@1b0fb9b |
Android appearance module fix |
Has this been reverted on main? |
Kotlin and Gradle bump maybe if possible, if not maybe in 0.67: |
@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 |
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 |
Please revert facebook/react-native@cb0e1d6 or pick facebook/react-native#32398 |
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 facebook/react-native@d1a33cd 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. 🚀 |
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? |
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 😁 |
The Android appearance module fix facebook/react-native@25a2c60 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: reactwg/react-native-releases#3 |
I guess I should say there is no such thing as a fast rn |
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:
The text was updated successfully, but these errors were encountered: