Skip to main content

Minor Stable Patches

info

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. Bump monorepo packages​

For 0.72 and higher:

Update all packages in the monorepo that were modified by the cherry picks. You can do it by running:

yarn bump-all-updated-packages # All the package bumps must be on the patch level
git push origin 0.XX-stable

After pushing, the CI will take care to publish the new packages automatically.

For 0.71:

yarn bump-all-updated-packages
git push origin 0.71-stable

This will trigger a CI pipeline that will publish the changed packages. Once those packages are published (the new versions are on npm), run:

yarn align-package-versions

For 0.70: For version 0.70, packages must be released manually by a Meta engineer.

3. Test the current changes​

Before continuing further, follow the testing guide to ensure the source code doesn't have any major issues.

info

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.

4. Run trigger-react-native-release 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"
yarn trigger-react-native-release --to-version x.y.z --token <YOUR_CIRCLE_CI_TOKEN>
info

For versions older than 0.70, you need to run ./scripts/bump-oss-version.js instead.

5. 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.

    CircleCI showing publish release
    CircleCI showing publish release.

  • Once complete you should be able to run npm view react-native and verify that under the latest 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

6. 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.

7. 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).

8. 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.

9. 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.

10. 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.

11. Verify that Upgrade Helper GitHub action has fired​

12. 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