search

react-native-community / releases

React Native releases
https://github.com/facebook/react-native/
1.5k stars 404 forks source link

Road to v0.65.0 - RC4 phase #242

Closed kelset closed 3 years ago

kelset commented 3 years ago

This issue serves to track the status of work to reach 0.65.0.

Current latest: 0.65.0-rc.4

Read this comment for more info on why we decided to do one more RC. We really hope that we can have a shorter lifespan on this RC4 and get to 0.65.0 soon šŸ¤ž

Left to do for 0.65.0

non code related

code related

Known issues

Commits (and PRs) to cherry pick

Non-blocking

Local commits to backport to main

Please limit your comments to reports of issues encountered with the RC and cherry pick suggestions. No ETA currently for when 0.65.0 will be released.

hramos commented 3 years ago

Thanks @kelset and @Titozzz for digging into the react-native-codegen issues. I think that applying https://github.com/facebook/react-native/commit/5f7deb5f1d17050ce399dd43a86495d5c3c8ba83 to 0.65, without upstreaming to main, is reasonable.

For context, we would not want this change in main because the code-gen files (FBReactNativeSpec.h and its Obj-C++ counterpart) can be derived from the JavaScript source files in Libraries/ by react-native-codegen, and we would not want to have conflicts in what react-native-codegen outputs at build time versus what is checked into the repository.

kelset commented 3 years ago

For context, we would not want this change in main because the code-gen files (FBReactNativeSpec.h and its Obj-C++ counterpart) can be derived from the JavaScript source files in Libraries/ by react-native-codegen, and we would not want to have conflicts in what react-native-codegen outputs at build time versus what is checked into the repository.

Thanks for clarifying - this is very close to our assumption for why the two files were ignored in the first place šŸ‘ I think that one consideration to do at a later point (when talking about RN OSS releases >= 0.66) is if we should bring this mechanism back more "formally"; meaning, when a release branch is out, we should revert the gitignore line about the two files so that at the local E2E test phase they will get generated and so they will be bundled with the "released" RN node module (which will, as it was done for 0.64 and 0.65) that ios builds will not fail.

tido64 commented 3 years ago

@hramos Is making react-native-codegen work more seamlessly and moving the dependency from the template into main package.json on FB's backlog? It would be great if we didn't have to spend so much effort on this next release.

mhammerc commented 3 years ago

I tried 0.65.0-rc.4 on my app.

Compilation on both Android and iOS on both debug and release works fine!

kelset commented 3 years ago

great report, thanks @mhammerc! We'll release 0.65.0 later today, hopefully the third party packages you listed will catch up quickly to the new release :)

nelsonprsousa commented 3 years ago

I tried 0.65.0-rc.4 on my app.

  • On iOS, I had set flipper to a specific version inferior to 0.93. It failed to build. But setting back the default value (use_flipper!()) fixed the compilation issue.
  • I had to patch the package react-native-keyboard-aware-scroll-view and react-native-blurhash because of api changes. (patch files/pr available on both repositories)
  • Works fine on iOS on debug and release! I had to disable react-native-codepush for release, otherwise the bundle could not be found šŸ¤”
  • On Android, I get loads of warning new NativeEventEmitter() was called with a non-null argument without the required removeListeners method.. I could not test my app further because react-native-reanimated crash (both debug & release).

Compilation on both Android and iOS on both debug and release works fine!

cc @mrousavy @piaskowyk

kelset commented 3 years ago

allright folks, 0.65.0 is out!

Thank you all for your support in getting to this point šŸ™ See you on the other side: https://github.com/react-native-community/releases/issues/244