Minor Stable Patches
Documents in this section go over steps to run different types of React Native release updates. Its intended audience is those in relevant release roles.
Pre-requisitesβ
- You have some pick requests that qualify for a patch release in the "should we release 0.Y.Z?" discussion.
- Write access to react-native repository.
- Write access to releases repository.
- One CircleCI personal API token - see here how to set one.
1. Check out the latest version from release branchβ
# Be on relevant release branch
# update the stable branch with tags
git pull origin <release-branch> --tags
# cherry pick relevant commits
git cherry-pick <commit>
2. Test the current changesβ
Before continuing further, follow the testing guide to ensure the source code doesn't have any major issues.
Since testing is a time consuming activity (>1 hrs) it is recommended that the release crew coordinates on the steps above then do testing on at least two separate systems in an async way.
3. Run bump-oss-version
scriptβ
# once verified all the cherry-picked commits, we can push them to remote
git push
# run a script to bump the version
# If you are doing this patch release for the current latest minor, then mark it as "latest"
./scripts/bump-oss-version.js --to-version x.y.z --token <YOUR_CIRCLE_CI_TOKEN>
4. Watch CircleCI to ensure right jobs are being triggeredβ
Once you have run the bump script script, head to CircleCI and you should see under the releases workflow, a
prepare-package-for-release
job.Once complete you should be able to run
npm view react-native
and verify that under thelatest
tag, the version is the expected release version.npm view react-native
...
dist-tags:
latest: 0.Y.Z next: 0.Y.0-rc.X nightly: 0.0.0-f617e022c
5. Create a PR of the changelog using the generatorβ
To generate the changelog, we rely on a dedicated tool called @rnx-kit/rn-changelog-generator
that will parse the custom changelog messages that contributors write in their PRs.
# Run following with the stable release as base, and your rc.0 version
npx @rnx-kit/rn-changelog-generator --base v[LATEST_STABLE]--compare v[YOUR_NEW_MINOR] \
--repo ~/react-native --changelog ~/react-native/CHANGELOG.md
# example against 0.68.2 and 0.68.3
npx @rnx-kit/rn-changelog-generator --base v0.68.2 --compare v0.68.3 \
--repo ~/react-native --changelog ~/react-native/CHANGELOG.md
Create a pull request of this change to react-native
repo and add the Changelog
label.
6. Create GitHub Releaseβ
Use template below for the GitHub Release:
<!-- Template for a stable patch -->
<!-- You can run `npx @rnx-kit/rn-changelog-generator --base v0.66.0 --compare v0.66.1 --repo path-to-repository/react-native --changelog path-to-repository/react-native/CHANGELOG.md` to generate the markdown for the cherry-picked changes. Make sure to use the right tags in the command and create a new PR with the changes generated by the changelog generator. You can read more about the changelog generator [here](https://github.com/microsoft/rnx-kit/tree/main/incubator/rn-changelog-generator). -->
- TODO Enumerate picks. <!-- use the changelog generated text for this section -->
---
You can participate in the conversation on the status of this release in this [discussion](TODO: your discussion link)
---
To help you upgrade to this version, you can use the [upgrade helper](https://react-native-community.github.io/upgrade-helper/) βοΈ
---
You can find the whole changelog history in the [changelog.md file](https://github.com/facebook/react-native/blob/main/CHANGELOG.md).
7. Upload prebuilt Hermes binaryβ
In the publish_release
CI workflow, the build_hermes_macos
step produces a tmp/hermes/output/hermes-runtime-darwin-vx.y.z.tar.gz
artifact, for example here are the artifacts for 0.69.0
release. Download it and attach it to the GitHub release.
8. Create a new patch discussion post using template belowβ
<!-- Template for new patch -->
# Should we release 0.67.1?
Current Release: [0.67.0](https://github.com/facebook/react-native/releases/tag/v0.67.0)
Conversations on this thread are limited:
- [major release issues](https://reactnative.dev/contributing/release-faq#what-is-release-blocking).
- [qualified cherry-pick requests](https://reactnative.dev/contributing/release-faq#what-is-a-qualified-pick-request) of commits on main that [did not make the previous patch version](https://reactnative.dev/contributing/release-faq#how-do-i-know-if-my-fixfeature-is-in-a-certain-release).
Please include a link to the specific commit on main to be cherry-picked, for example: [facebook/react-native@bd2b7d6](https://github.com/facebook/react-native/commit/20b0eba581a00e5e7e300f6377379b836617c147)
In other words, if you cannot point to a particular commit on main, then your request likely belongs as a new issue.
If the issue is a [major release issues](https://reactnative.dev/contributing/release-faq#what-is-release-blocking), please reference the issue here.
---
#### List of qualified picks
<!-- Keep these in chronological order in time of commit -->
1.
#### Local commits to backport to main
1.
9. Update "should we release 0.Y.Z?" discussion postβ
- Label it
Released
. - Update the text body saying the patch has been released and link to new patch discussion.
- Lock the discussion.
10. Verify that Upgrade Helper GitHub action has firedβ
- You should see a new publish job here.
- Once it has finished, you should be able to see that the Upgrade Helper presents the option to target the new minor.
- If not, check out the guide on how to update Upgrade Helper.
11. Communicate the new releaseβ
Once all the steps above have been completed, it's time to signal to the community that latest minor is available! Do so in the following channels:
- @reactnative on twitter (with a link to the GitHub release)
- RN Discord
#releases-coordination