Skip to content
This repository has been archived by the owner on Jun 17, 2022. It is now read-only.

Potential v0.66.1 Patch Release #254

Closed
lunaleaps opened this issue Oct 1, 2021 · 22 comments
Closed

Potential v0.66.1 Patch Release #254

lunaleaps opened this issue Oct 1, 2021 · 22 comments
Labels
backport request Cherry picking a change into an existing release stable Stable version

Comments

@lunaleaps
Copy link
Collaborator

lunaleaps commented Oct 1, 2021 •
edited
Loading

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:

  • revert facebook/react-native@1b0fb9b - a UX regression for pull to refresh
    • To revert on this patch, I think we need to agree that this commit should be reverted on main. Can someone advocate for that? See comment and context.
@lunaleaps lunaleaps added stable Stable version backport request Cherry picking a change into an existing release labels Oct 1, 2021
@mikehardy
Copy link

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
facebook/react-native@51bf557

My only hesitation on those (other than "needs testing") is that I'm not sure of the implications with regard to transitive dependencies. Specifically:

  • I'm not sure if those also bring in the requirement for cocoapods >= 1.11 or not,
  • "deprecate the __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

@lubomyr
Copy link

lubomyr commented Oct 2, 2021 •
edited
Loading

request (fix ios release build via xcode)
facebook/react-native@cc59a7c

@gaodeng
Copy link

gaodeng commented Oct 3, 2021

please revert facebook/react-native@1b0fb9b
Related Discussion
facebook/react-native#31461
facebook/react-native#28236 (comment)

@lunaleaps lunaleaps mentioned this issue Oct 6, 2021
Closed
30 tasks
@svbutko
Copy link

svbutko commented Oct 6, 2021 •
edited
Loading

Android appearance module fix
facebook/react-native@25a2c60

@lunaleaps
Copy link
Collaborator Author

please revert facebook/react-native@1b0fb9b Related Discussion facebook/react-native#31461 facebook/react-native#28236 (comment)

Has this been reverted on main?

@svbutko
Copy link

svbutko commented Oct 13, 2021 •
edited
Loading

Kotlin and Gradle bump maybe if possible, if not maybe in 0.67:
facebook/react-native@9ae3367

@radko93
Copy link

radko93 commented Oct 13, 2021

@svbutko I don't that will be included in 0.66.x. You can also upgrade gradle yourself.

@svbutko
Copy link

svbutko commented Oct 13, 2021

@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

@mikehardy
Copy link

mikehardy commented Oct 13, 2021 •
edited
Loading

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]

@svbutko
Copy link

svbutko commented Oct 13, 2021

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

@oblador
Copy link
Member

oblador commented Oct 13, 2021

Please revert facebook/react-native@cb0e1d6 or pick facebook/react-native#32398

@mikehardy
Copy link

That PR (32398) hasn't landed (since you made it...2 hours ago :-) ) but I just looked and it looks great IMHO

@aliraza-noon
Copy link

@mikehardy it has been merged so i think we good to pick

@mikehardy
Copy link

@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. 🚀

@lunaleaps
Copy link
Collaborator Author

lunaleaps commented Oct 14, 2021 •
edited
Loading

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?

@mikehardy
Copy link

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 😁

@lfiorini
Copy link

lfiorini commented Oct 15, 2021 •
edited by kelset
Loading

-- what do you guys think?

The Android appearance module fix facebook/react-native@25a2c60 is a block for my app.

@lunaleaps
Copy link
Collaborator Author

lunaleaps commented Oct 15, 2021 •
edited
Loading

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

@lunaleaps
Copy link
Collaborator Author

0.66.1 is out: https://www.npmjs.com/package/react-native

@lunaleaps
Copy link
Collaborator Author

Let's have any 0.66.2 in this discussion: reactwg/react-native-releases#3

@mikehardy
Copy link

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

@divinghero

This comment has been minimized.

Sign in to view
@react-native-community react-native-community locked as resolved and limited conversation to collaborators Oct 25, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
backport request Cherry picking a change into an existing release stable Stable version
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
10 participants
@oblador @lubomyr @mikehardy @gaodeng @lunaleaps @lfiorini @divinghero @radko93 @svbutko @aliraza-noon