As mentioned in Meta’s H2 2021 plans, React Native is attempting more frequent releases for a shorter turnaround time for new features and fixes (like the new architecture) to land in the community. Naturally, many releases will focus on fixes and improvements.
Here are some notable changes coming in 0.67.0:
You can find the full changelog here.
You can participate in the conversation on the status of this release at this discussion – and, as always, to help you upgrade to this version, you can use the upgrade helper ⚛️
This release includes 379 commits with 74 contributors! Thank you, to all our contributors (old and new)! You can find the full changelog here.
We wanted to also thank the release testers who helped us make sure that 0.67.0 could reach your codebases without any massive regression. Specifically, we wanted to thank:
We appreciate also Rainbow, Comm and Ledger Live for also being part of the pilot of the “Release Tester” program (more details below).
As mentioned, React Native has been restructuring the release pipeline to allow for more frequent releases such that new features and fixes can roll out faster to the community.
Over the last few months we tackled some issues that delay releases.
We invested in our documentation of releases to cover how to run a release, FAQs, coordination of release issues, etc – all of which can be found in this section of the react-native wiki. By documentation, releases are no longer blocked on any individual or tribal knowledge.
In addition to documentation, we have also revamped the coordination of releases and have moved discussion of pre-release status and patches to a dedicated discussion group: react-wg/react-native-releases.
Following more documentation, release work can scale such that no one person is critical to running a release.
A React Native release is susceptible to a broad spectrum of potential points of failure and has a lot of dependencies and follow-up. Considering that usage of React Native varies across the community, it’s essential to have stakeholders involved in releases. We have defined a set of roles and responsibilities in supporting a release.
Another issue with releases is getting a good signal that a release will not suffer from build regressions. This can be addressed with growing investment in testing build variants, etc. but signal from adoption will continue to be useful for some time.
In the 0.67 release we piloted a “Release Tester” program where React Native developers working on Open Source apps commit to testing release candidates on their apps. Prior, there was no formal expectation that the community will test out release candidates to raise any potential issues. This program helps us get faster signal to ensure a level of stability of the release.
Open source React Native apps are particularly useful due to availability of source code to help debug any regressions. With this program in place, a release tester surfaced a regression in 0.67 and we were able to resolve it without thrashing the larger community with a faulty release.
A great way to help us catch regressions is to integrate the React Native pre-release version
react-native@nightly to your CI. For any regressions, you can file a release issue and notify the appropriate discussion.
If your app or company is interested in joining the “Release Tester” program, head to the dedicated section at the bottom of the Release Roles and Responsibilities wiki to learn more.
Lastly any help on trying our release candidates or helping unblock release issues is much appreciated!
Leave a Comment