Should we release 0.71.12?

[kelset]

Released, please refer to #78

---

Current Release: 0.71.11

Conversations on this thread are limited:

• major release issues.
• qualified cherry-pick requests of commits on main that did not make the previous patch version.

Please include a link to the specific commit on main to be cherry-picked, for example: 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.
If the issue is a major release issues, please reference the issue here.

---

List of qualified picks

1. react/react-native@cd56347
2. Add web compat unit tests and fixes react/react-native#37876
3. fix(ios): fix pod install --project-directory=ios failing react/react-native#37993

Local commits to backport to main

[kelset]

from @AlexanderEggers and @NickGerleman:

It would be great to backport react/react-native@3681df2 to fix react/react-native#37797.

PR for 0.71 branch -> react/react-native#37876

[Saadnajmi]

Could we pick react/react-native@8b1bf05 ?

[cortinico]

but a compatibility note we should consistently highlight in release notes and our website. cc @cipolleschi @cortinico @lunaleaps @rickhanlonii

For context: on Android, the AGP version creates the lowerbound of the Android Studio version that is supported (as described here https://developer.android.com/studio/releases#api-level-support).
So for example 0.71 shipped with AGP 7.3.1 which means Android Studio Dolphin or later releases. 0.72 ships with AGP 7.4.x == Android Studio Electric Eel or later. Etc.

We can totally add compatibility notes somewhere

[Saadnajmi]

With Apple in my experience, it's generally harder to enforce compatibility beyond "Use the latest Xcode version". We're kind of forced to use the latest version of Xcode as soon as it comes out and it's generally a flurry of "update CI everywhere and go make fixes". With other projects I've been involved in, I don't think we've ever made any sort of "We support this many versions of Xcode" kind of agreement, only "We fixed the bugs we found with the latest Xcode, and here are the versions of iOS or macOS we support". That's also why I wrapped the call in OS check, that's fairly standard practice.

In this case, I understand that we can't really force all projects to update their CI to not-yet-the-standard-image in a patch release. I'm happy to revisit this change in the future, hopefully too many users aren't impacted.

[liamjones]

Possibly relevant to the discussion; Apple currently mandate only Xcode 14.1+ for uploads to the store (as of April this year): https://developer.apple.com/news/upcoming-requirements/?id=04252023a

[Saadnajmi]

I'll see if I can make a version that uses compile time checks to be backwards compatible, but I think mostly likely this will not get backported.

[Saadnajmi]

Found in Availability.h. Might give us a compile time check we can use.

    It is also possible to use the *_VERSION_MIN_REQUIRED in source code to make one
    source base that can be compiled to target a range of OS versions.  It is best
    to not use the _MAC_* and __IPHONE_* macros for comparisons, but rather their values.
    That is because you might get compiled on an old OS that does not define a later
    OS version macro, and in the C preprocessor undefined values evaluate to zero
    in expresssions, which could cause the #if expression to evaluate in an unexpected
    way.
    
        #ifdef __MAC_OS_X_VERSION_MIN_REQUIRED
            // code only compiled when targeting Mac OS X and not iPhone
            // note use of 1050 instead of __MAC_10_5
            #if __MAC_OS_X_VERSION_MIN_REQUIRED < 1050
                // code in here might run on pre-Leopard OS
            #else
                // code here can assume Leopard or later
            #endif
        #endif

[kelset]

react/react-native#37993

[hannojg]

This is a workaround for android API 33+ that prevents ANRs from happening: react/react-native@90186cd

Would appreciate to see it in a patch version 🙌

[liamjones]

This was reverted: react/react-native#37913 (comment)

[kelset]

good catch: there are now two PRs:

• [Native part] Add workaround for android API 33 ANR when inverting ScrollView react/react-native#38071
• Add workaround fix for #35350 react/react-native#38073

[evelant]

Can react/react-native@e3abbc2 get into the next patch release? It's a serious DX drag to have the dev app freeze up all the time due to logbox crashing.

[joe-sam]

Actual commit is probably merged @ Prevent LogBox from crashing on long messages (react/react-native#38005)
LogBox related fixes should after some nightly testing be immediately backported to all supported latest RN releases as these are definitely show-stopping bug fixes and can save loads of time for developers.