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 hermes repository.
- Write access to releases repository.
- One CircleCI personal API token - see here how to set one.
Add a new column for this release candidate in the External Dependencies Supported table. Follow up internally if unsure.
- 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 a similar branch in the @react-native-community/template project
- Check-out a clone of
@react-native-community/templaterepo - Pull
main - Create a release branch. It must be of the form
<major>.<minor>-stable - Push the branch up to
origin.
git checkout main
git pull origin main
git checkout -b 0.76-stable
git push --set-upstream origin 0.76-stable- 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 from steps 4-13
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.75.0-rc.0, then
js1 publish react-native 0.76.0-mainThis will update all the relevant packages to 0.76.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.74.0-rc.1 -> 0.74.0-rc.2
Promoting 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.
1. Release a stable version following release process
Update the support policy for the new version.
- The first line should contain the
Next Releaseand the status must beNot Started - The other lines must be updated by bumping the versions in the first column by 1 minor
So, for example, if the table contains:
| Version | Type | Status |
| ---------- | --------------------- | ---------------- |
-| 0.72.x | Next version | Not started |
-| 0.71.x | Latest stable | In support |
-| 0.70.x | Previous minor series | In support |
-| 0.69.x | Previous minor series | In support |
-| <=0.68.x | Old minor series | Unsupported |
+| 0.73.x | Next version | Not started |
+| 0.72.x | Latest stable | In support |
+| 0.71.x | Previous minor series | In support |
+| 0.70.x | Previous minor series | In support |
+| <=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