Note
Release Candidates will primarily handled by Meta release crew. Community releasers can aid in testing and triaging issues.
The general stages for handling a release candidate:
- Write access to react-native repository.
- Write access to template repository.
- Write access to hermes repository.
- Write access to releases repository.
Tip
The whole branch cut is automated by cut-branch. Its interactive workflow: verifies your repo state, checks CI on main, prompts you to update the external dependencies table, creates the X.Y-stable branch (and the matching branch in react-native-community/template), notifies the #cli Discord channel, triggers a nightly, walks you through the Hermes release and version bump, and prints the follow-ups.
Preview with --dry-run first, then run it for real:
npx rn-release-automator@latest cut-branch --series 0.85 --dry-run
npx rn-release-automator@latest cut-branch --series 0.85When it finishes, continue with create-github-project and prepare-release. The manual equivalents of each phase are below and in the linked general release process.
Manual steps — cut the branch by hand (steps 0–3)
Add a new column for this release candidate in the External Dependencies Supported table. Follow up internally if unsure.
Consider opening a new pull request rather than committing directly to main as viewers of the react-native-release repo will be notified.
- Check-out a clone of
react-nativerepo - Pull
main - Create a release branch. It must be of the form
<major>.<minor>-stable
git checkout main
git pull origin main
git checkout -b 0.76-stableCreate corresponding release branches in related community repos
- @react-native-community/template
- Example:
0.76-stable
- Example:
[!CAUTION] Make sure the CLI team (#cli channel on discord) is aware of the upcoming branch cut. They are responsible of making sure the CLI is bumped before RC1.
Things to be aware are:
- Make sure there is a corresponding release branch on @react-native-community/cli
- Make sure the compatibility table gets updated here
With repo write permissions, you can do this from the GitHub UI.
- Follow instructions to publish a Hermes release tag
- Make sure to have committed the Hermes tag to your release branch.
Some partners are integrating with the nightlies jobs, so it's a good idea to trigger a nightly right before cutting the branch so that they can integrate with it before we push some release specific fixes in the Release branch.
To trigger a nightly:
- Navigate to https://github.com/facebook/react-native/actions/workflows/nightly.yml
- Select the
Nighlyaction. - Click on
Run workflow. - Keep the branch on
main. - Click on
Run workflow.
At this point, you'll follow the general release process as per the following links:
Note
The changelog for the release candidate may be quite long and will need some manual curation. In addition, the changelog parser can be flaky and mis-parse some commits. Here are guidelines for editing the changelog
- Remove any commits that are marked "Internal" or are clearly not relevant to React Native OSS developers
- Examples: commit on BUCK files or code refactoring that do not change behaviours or interfaces
- Delete dependency bump commits that are superceded by later version bumps.
- Ex. Delete the commit for bumping X dependency to 0.7.0 if there is a commit to later bump X to 0.8.0
- At the end of the generated Changelog, there could be two additional sections: the Failed to Parse section and the Unknown section.
- The Unknown section is populated with commit that landed without the
## Changelog:entry in the summary. - The Failed to Parse section contains commits that has a
## Changelog:entry in their summary but, due to typos or other problems, the tool was not able to parse and automatically attribute them to the right section. - For both these categories, we have to manually go through the listed commits and move them to the right section, based on the actual change they introduce.
- The Unknown section is populated with commit that landed without the
Now we've cut a release branch, we need to update main monorepo packages and internal Meta dependencies to point to the "next" version.
In fbsource run
js1 publish react-native 0.<your-release-candidate-minor+1>.0-main
# ex. if you just released 0.78.0-rc.0, then
js1 publish react-native 0.79.0-mainThis will update all the relevant packages to 0.78.0-main
You can follow the general release process for patches. The only thing to note is that your versioning scheme should be increasing the prerelease version.
ex. 0.78.0-rc.1 -> 0.78.0-rc.2
With the CLI, prepare-release detects the current RC and offers the next one automatically:
npx rn-release-automator@latest prepare-release --series 0.85 # choose "Next RC"
npx rn-release-automator@latest publish --version 0.85.0-rc.2 --dry-run
npx rn-release-automator@latest publish --version 0.85.0-rc.2Promoting a release candidate to stable is similar to releasing a patch. The difference is now we are releasing the new latest version.
As well, there is follow-up in terms of writing a blog post and communicating to the ecosystem about this release.
Tip
With the CLI, promote and then run the post-promotion follow-ups:
# 1. Release the stable version (choose "Promote to stable" when prompted)
npx rn-release-automator@latest prepare-release --series 0.85
npx rn-release-automator@latest publish --version 0.85.0 --dry-run
npx rn-release-automator@latest publish --version 0.85.0
npx rn-release-automator@latest verify-release --series 0.85
# 2–4. Support policy table, blog post, and website version cut
npx rn-release-automator@latest post-promotion --series 0.851. Release a stable version following release process
In the CLI, run prepare-release --series 0.85 and choose Promote to stable, then publish --version 0.85.0 (with --dry-run first) and verify-release --series 0.85.
Steps 2–4 below (support policy table, blog post, website version cut) are all driven by post-promotion --series 0.85. It generates the updated support-policy table for you and can open the file in the GitHub editor or copy the table to your clipboard, then opens the website PRs page and version-cutting instructions.
Manual steps — post-promotion follow-ups by hand (steps 2–4)
Next, let's update the releases table for the upcoming version of React Native.
Files to update:
Example:
| Version | Type | Status |
| ----------- | -------------------------- | ---------------- |
-| 0.72.x | Next version | Future |
-| 0.71.x | Latest stable | Active |
-| 0.70.x | Previous (-1) minor series | Active |
-| 0.69.x | Previous (-2) minor series | End of Cycle |
-| <=0.68.x | Old minor series | Unsupported |
+| 0.73.x | Next version | Future |
+| 0.72.x | Latest stable | Active |
+| 0.71.x | Previous (-1) minor series | Active |
+| 0.70.x | Previous (-2) minor series | End of Cycle |
+| <=0.69.x | Old minor series | Unsupported |- Head to react-native-website
- Make sure all relevant PRs for release candidate are merged
- Cut a new version of the website, instructions