Road to 0.68 - part 2

[kelset]

0.68.0 is RELEASED! Conversation continues here: #19

---

The branch cut has happened.

Notice

• Current release candidate: 0.68.0-rc.4
• Have an issue with current release candidate? File an issue and we will triage.
• Have a pick request for this release? Does it fall under our pick request qualifications? If so please create a PR against the release branch and comment with the PR link
• If you are release testing. Copy and fill Release report form

Highlighted Changes in this release

• Checkout this Changelog PR
• RN0.68 will use AGP 7.0.x, not 7.1. See this comment for more details.

Release Process

Checklist

• Changelog PR
• Start a Google doc of blog post for release and invite contributors of release highlights to expand
• cut new docs version on react-native-website Generate 0.68 version of the docs react/react-native-website#3033
• Follow up on release dependencies

When ready to publish stable

• Ship changelog Changelog for 0.68 react/react-native#32993
• Ship blog post blogpost for 0.68 react/react-native-website#3041
• Notify react-native-website to ship new version Generate 0.68 version of the docs react/react-native-website#3033

Retrospective Topics

• add me

Release Status

0.68.0-rc.5

Tracking issues for 0.68.0-rc.5

• add me

Picks for 0.68.0-rc.5

• add me

0.68.0-rc.4

Picks for 0.68.0-rc.4

• react/react-native@b5343a6

---

For previous RCs conversation, please refer to the previous discussion.

[kelset]

should we pick the bumps to minimum iOS version?

• react/react-native@982ca30
• react/react-native@c71e6ef

[danilobuerger]

I don't see a real advantage in picking them for 0.68 as this release should just work fine with 11.0 - 12.3, so why limit devs? Devs still supporting 11.0 would then be stuck with 0.67 instead of 0.68.

[kelset]

fine by me, that's why I was asking if we should ;)
Given that iOS 15 is current latest, I assumed not many folks would still need 11 around

[fortmarek]

Considering there have been some changes in third-party podspecs (such as here), it might be a good idea to pull in this change:
react/react-native@b2517c3

The version of the third-party local podspecs have not changed afaict though, in which case the commit would not make a difference when bumping from 0.67.x. It would still update those podspecs automatically if you upgraded from previous React Native versions.

Tangentially, should the version be bumped when the podspec itself is changed or is that not related?

[mikehardy]

👋 from the developing world, and also from a planet struggling with so many humans. When fundamental frameworks bump minimum device requirements it pushes a bunch more old devices - that are the only devices many people have (that "7%" missing in the quote "93% of devices are on ios14") - closer to the landfill. I urge everyone involved in any decision like that to consider carefully if an n-1 policy is important for fundamental technical reasons or if it's just more convenient.

[fortmarek]

Hey @mikehardy 👋
To clarify, I am not advocating for making the bump of iOS version. The commit linked actually is not even cherry-picked (my mistake). The rest of the points still stand, though.

[fortmarek]

Given we are close to actually making a release, this commit is not crucial enough to be included in the current release, so I'd drop it and release it with 0.69 instead.

[Megatron4537]

Tested commits run/android/0.68.0-rc3 and everything was good!

I am curious if this take took a long time for you? for me it would take ~5-10 minutes every gradle clean and new builds

> Task :ReactAndroid:downloadLibevent
Download https://github.com/libevent/libevent/releases/download/release-2.1.12-stable/libevent-2.1.12-stable.tar.gz

[mikehardy]

I'm not sure if that's something to enable by default in the framework, note that brew on purpose will not use it even if installed, you have to manually force it's use for brew and then I think they won't take bug reports. So apparently there is a support cost. (reference, check the note: https://formulae.brew.sh/formula/ccache)

But I personally use it for the iOS part of the compilation and it is quite the accelerator, yes.

That argues for something that allows it's use but does not use it by default. Similar to this to allow it for iOS compilation but it's certainly not the default https://github.com/invertase/react-native-firebase-authentication-example/blob/68bd37f8c219f892655b40c73e9818370f368b82/template/ios/Podfile#L39-L43

[leotm]

For me it was a mismatch between the jdks and my cpus arch. Once I installed an arm64 jdk on my m1 mac, the build time was reduced in half.

similar here after upgrading Android Studio Preview Canary via the site or brew (cask)

think my JDK's resetting to AdoptOpenJDK 11 each time, then ok again after reverting back to (Adoptium) Eclipse Temurin 11

[mikehardy]

For me it was a mismatch between the jdks and my cpus arch. Once I installed an arm64 jdk on my m1 mac, the build time was reduced in half.

think my JDK's resetting to AdoptOpenJDK 11 each time, then ok again after reverting back to (Adoptium) Eclipse Temurin 11

@leotm 🤔 but adoptium temurin 11 is only x86_64 right now (I just checked). There are plans for arm64 backport to release soon for Temurin11 but right now only arm64 JDK11 is Azul Zuzu. If you are reverting to Temurin 11 right now, you are not getting the native-arm64 speed boost that @danilobuerger was describing

[leotm]

gotcha rip my m1 android build bens this whole time 😅 been sticking w docs (next) (this part)

i'll raise that M1/arm64 JDK note @mikehardy in reactwg/react-native-new-architecture#7 if i'm understanding right (and strictly note perf metrics from now on)

edit: actually that doesn't look like the right place, i'll find the repo of the docs and PR a note/suggestion
Edit this page doesn't seem like the right place either 🤔

and figure if it's pos stopping JDK reset per upgrade

---

i remember now in github.com/actions/setup-java#basic Zulu OpenJDK 2nd option

not Zuzu (; thx again

[cortinico]

We're going to have an official guide about this specific issue here:

• [Guide] Speeding up your Android/iOS Build react/react-native-website#3027

[kelset]

we need this: react/react-native#33499 - commit react/react-native@b5343a6

[tido64]

@cortinico: react-native-gradle-plugin is not requiring the same version of react-native-codegen as core does. Is this going to be an issue?

% yarn why react-native-codegen
├─ react-native-gradle-plugin@npm:0.0.5
│  └─ react-native-codegen@npm:0.0.14 (via npm:*)
│
└─ react-native@npm:0.68.0-rc.4 [6dfc2]
   └─ react-native-codegen@npm:0.0.13 (via npm:^0.0.13)

[cortinico]

Not really, as react-native-gradle-plugin is not having any js code, and is not consuming any dependency. That dependency could probably be removed entirely

EDIT: Actually, It might. I'm looking into it as we might have to remove that dependency (react-native-gradle-plugin -> react-native-codegen) entirely for 0.68.0.

[cortinico]

Just checked and nope, it's not a problem.

You're going to have react-native-codegen@npm:0.0.14 inside node_modules/react-native-gradle-plugin/node_modules/react-native-codegen/ which is, I agree, not great.
However, as react-native-gradle-plugin contains no js code, that dependency is essentially ignored.

To mitigate this scenarios, I will replace the "*" from https://github.com/facebook/react-native/blob/d2e8e7d58e680e0bb3b4da1f820dd4dd840639f5/packages/react-native-gradle-plugin/package.json#L27 with the latest released version of "react-native-codegen" so this won't happen again in the future.

[douglowder]

@kelset should react/react-native#33500 (react/react-native@58a2eb7) be pulled in?

[kelset]

not sure - it's a bit unclear to me how widespread the problem it tackles is. Maybe it's worth considering for 0.68.1 instead? I'll defer to @ShikaSD / @cortinico since it's Android specific (and seems related to new arch?)

[ShikaSD]

It is needed for Reanimated to work with the new arch, I believe we can skip it for now

[douglowder]

Thanks @kelset @ShikaSD ... I can cherry-pick to react-native-tvos if needed

[cortinico]

I believe we can skip it for now

Agree. I think we can point release, if Reanimated fully migrates to new arch.