Should we release 0.66.2?

[lunaleaps]

Current Release: 0.66.1, related issue

0.66.2 has been released -- locking this discussion and moving discussion to 0.66.3

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 main but did not make the 0.66.1 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 main, then your request likely belongs as a new issue.

List of cherry picks

• facebook/react-native@5f7deb5
• Hide the logbox window explicitly. facebook/react-native@72ea0e1
• fix: compare the LogBoxData ignorePatterns with the right code facebook/react-native@a950634

Local commits to backport to main

[Sandy-Garrido]

facebook/react-native@c4cd447 - Issue #32372 There seems to be a problem running jest, the preprocessor.js from 0.65.1 works okay but since 0.66 it has been a problem and could halt our iOS 15 support

[LukePurtell]

We are also having this issue upgrading from 0.65.1 to 0.66.1. Our entire test suite fails with a similar issue that seems to stem from the jest preprocessor.

[lunaleaps]

Great! It sounds like there's a solution, we can pick it in if someone submits a PR and links it here 😄

[Sandy-Garrido]

Great! It sounds like there's a solution, we can pick it in if someone submits a PR and links it here 😄

A solution hasn't been merged into main, it would be to revert the changes made to preprocessor.js on this commit facebook/react-native@c4cd447. I think I misunderstood how this works. I guess for this to be cherry picked, the revert would need to be merged into main already, which it's not so this fix is out of the question.

[lunaleaps]

This seems like a pretty critical issue. I think if we can get a PR with a fix, we can merge to main and pick into here. I think submitting a PR with what you needed to do to fix (maybe you don't need a full revert, etc) will help start a discussion with @rubennorte and team about what the underlying issue is with facebook/react-native@249b8d2

[diegotsi]

Any news ?

[joe-sam]

Hide the logbox window explicitly. #32435.
Ok, this is not as yet merged or tested but can see immediately that it a good hack that would probably be really, really super useful !!!

fix: compare the LogBoxData ignorePatterns with the right code #31977
This has probably baked in long enough to be stable.

[lunaleaps]

We have a policy of picking in changes that are critical to developer workflow. Can you expand on why this is critical to have in for 0.66.2?

[joe-sam]

I understand that for almost all basic build processes and minimal testing apps the LogBox may not be a necessity.

However in my view, for the vast majority developers to have confidence in an Release Candidate or Release, the runtime debugging user experience on the front end user interface should be improved to a pleasant degree and be accurate and reliable and factor out all the redundancy, and should also be easily configurable as well.

While not absolutely critical, these fixes do appear to align to this viewpoint.

To that end I would even go so far to suggest that LogBox library should probably be as independent from the React-Native in the same way that all the other superfluous components are being removed from the core, but that would be the topic for a different forum.

[lunaleaps]

Picked both in