Should we release 0.68.1?

[kelset]

RELEASED - please refer to #20 for 0.68.2

---

Current Release: 0.68.0

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@20b0eba

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 issue, please reference the issue here.

---

List of qualified picks

1. facebook/react-native@58a2eb7
2. facebook/react-native@5dff920
3. facebook/react-native@5534634
4. facebook/react-native@44ee801
5. facebook/react-native@4befd2a
6. facebook/react-native@e48a580
7. Bump React Native Gradle plugin to 0.0.6 facebook/react-native#33581 Which includes the following fixes for for react-native-gradle-plugin facebook/react-native@9573d7b (version bump of react-native-gradle-plugin) facebook/react-native@48113b5 (update yarn.lock with the version)
   1. facebook/react-native@d5da70e
   2. facebook/react-native@34628ac

Local commits to backport to main

[kelset]

as per conversation with @douglowder, we should cherry pick this: facebook/react-native@58a2eb7 for reanimated to work correctly with the new arch

[kelset]

We want to address this: facebook/react-native#33525

[cortinico]

Kudos to @danilobuerger for sending this super quick fix:

• Replaced windowsAwareYarn with windowsAwareCommandLine for node calls facebook/react-native#33530

I'm working on making this land.
The trick would be that we'll have to cherry-pick a bump of the react-native-gradle-plugin package (plus we need a point release for that NPM package, which is something that we'll have to do manually).

[tido64]

Since you're already cherry-picking a bump, can you also remove react-native-codegen from dependencies?

[cortinico]

Yup that already landed: facebook/react-native@34628ac

[danilobuerger]

Commit is at facebook/react-native@d5da70e

[cortinico]

This has been included inside facebook/react-native#33581
RNGP 0.0.6 is now on NPM and contains the two fixes. I've verified that it works correctly with a RN 0.68 project so can safely be backported.

[myckhel]

Dropping incase this would be useful:

After upgrading to rn v0.68.0 and you came across this error Build input file cannot be found: '**/ios/**/AppDelegate.m' and you are the type of person that ignores collapsed project.pbxproj from upgrade-helper, just know that you might have omitted a very important change from that file which changed AppDelegate.m to AppDelegate.mm.

In order to fix this

Open the project in XCode, then navigate to Build Phases, in Compile Sources remove the AppDelegate.m file and add AppDelegate.mm instead.

[kelset]

I checked and in the upgrade-helper it shows up like so:

I think that's a good enough indication of the change, but thanks for adding the comment here! Let's see over time if more folks hit your same issue

[leotm]

It's indicated at the top too:

Just in case still missed I've suggested a comment pointing to iOS: Use Objective-C++ (.mm extension)

[Adnan-Bacic]

im on xcode 13.3 for reference

when i add the AppDelegate.mm file through the steps you mentioned, it gives me a dialog.

do we just keep the default boxes checked? or do we change anything

[myckhel]

Well for me i kept them checked but i didn't understand why i should or not.

[danilobuerger]

We should look into facebook/react-native#33555 which is a regression caused by the introduction of bundler / ruby version. This should be reworked as both methods of installing cocoapods (gem / homebrew) are incorrect, and it should use bundler instead. The linked issue is caused by the fact that gem install of cocoapods is not invoked in the rn project dir but one up and so it uses a different ruby version.

[kelset]

What will affect stock ruby is the Gemfile, but there we could (and should!) use a range specifier instead (>= 2.7 as that is what cocoapods needs currently).

ok and this can be done within your PR too? Sorry I'm not a master of Ruby, I'm just trying to wrap my head around what changes are "breaking" vs what is just "relaxing" existing boundaries

[danilobuerger]

Yeah so if we set .ruby-version to 3.1.1 the ruby version managers should just pick that up and it will only be valid for that folder and subfolder. Depending on the version manager it requires a command to install that version if it was not previously installed. For example rbenv will error out with:

rbenv: version `3.1.1' is not installed

which is then fixed by

❯ rbenv install

Normal ruby without a version manager ignores .ruby-version afaik.

For the Gemfile, bundler will complain if the version is a mismatch:

❯ bundle install
Your Ruby version is 2.7.4, but your `Gemfile` specified 3.1.1

Thats why I would set the ruby version requirement in the Gemfile to >= 2.6 which is the min requirement for cocoapods. This would then even work with the mac stock ruby version without having to install a different one.

[kelset]

thanks for the great explanation! That sounds like a perfect approach 👍

[mikehardy]

I think cocoapods is >= 2.7, otherwise, if this works, fantastic until 3.1.2 comes out, then we'll be back to the start.
What really would happen if we just deleted .ruby-version ? (and why doesn't ruby version allow range specification, I tried and it did not work for me - would solve the whole thing if we could just provide unbounded upper end)

[danilobuerger]

I think cocoapods is >= 2.7,

From https://blog.cocoapods.org/CocoaPods-1.11.0-beta/ :

CocoaPods 1.11 raises the minimum Ruby version to 2.6

I don't think having the .ruby-version around is such a big problem. When you don't have a ruby version manager installed, this file is simply ignored. If you have one, it will use that version only for that folder and subfolders. If x.y.z comes out and we still use 3.1.1 it doesn't affect any other project on your machine. And once we validate that x.y.z works we can bump it. (I believe that was the intention of the initial inclusion of this.)

But yes, not much will change if we simply remove that file. I think the inclusion of the Gemfile (and therefor the version range of cocoapods) is far more important than the ruby version which seems to have always worked fine (except that one time that might have triggered the inclusion of those files with ffi and m1).

Maybe it was just a bit premature without having the docs and react-native init updated?

[douglowder]

For the AppDelegate.mm change I just edited the project.pbxproj file and did a global replace of AppDelegate.m -> AppDelegate.mm... worked great for me

[danilobuerger]

We might need facebook/react-native@5534634
This keeps the use-subscription dependency under v1.6.0 which in turn started to depend on react 18.

[kelset]

yeah good shout, I've seen a couple folks getting hit by this 👍

[fortmarek]

Thanks @danilobuerger - I've added it to the list of commits to cherry-pick 👌

[kelset]

The fix for the Windows + Android + New Arch is being worked on here: facebook/react-native#33582 I think it'd be good to see it merged for the 0.68 branch and then do 0.68.1.
Then a separate conversation will have to be had on how to backport this to main and/or if it's just a matter of "reverse cherry pick" it - I'll let @cortinico and @mganandraj deliberate on that ;)

[cortinico]

I'd say for this we should be fine merging this on main + cherry-pick on 0.68

[cortinico]

I've worked on a fix for M1 users on Android with the New Architecture:

• Improve support for Android users on M1 machine facebook/react-native#33588

This will make sure users can build on M1s without having to patch their environments (i.e. edit the ndk-build file) in any form. We might want to include this into a patch for 0.68.x

EDIT: Clarify that this is for new arch

[yotamishak]

Thank you for this 🙏

[jspizziri]

Would it be possible to get facebook/react-native@dac56ce cherry-picked and into this patch?

[fortmarek]

Hey @jspizziri 👋

This does not seem as a regression in 0.68. Is there a specific reason we'd want this included in 0.68.1 already or can it wait for 0.69?

[jspizziri]

Hey @fortmarek , thanks for the response. First time looking into the RN release process, but I did read the literature provided via links in the comment descriptions and I think I just misunderstood: "Is a fix for an issue introduced in current release.". This particular issue doesn't seem to have been a regression between 0.67 & 0.68, so it sounds like it's not a candidate for a patch under that criteria.

Sorry for the confusion!

[fortmarek]

Hey @jspizziri! Yeah, the phrasing is not entirely clear, sorry for that 🙇 I would then wait with this for 0.69. You can always patch this and we'll also soon start iterating on the 0.69 release.

[jspizziri]

@fortmarek thanks for the help! FYI, I created an MR to clear up the language in the event that it's helpful.