Skip to main content

Branch Cut & RC0


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.


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

1. Creating a new release branch​

  • Create the release branch in react-native repo with the appropriate name (usually 0.XX-stable).

    git checkout main
    git pull origin main
    git checkout -b 0.69-stable

2. Update the Hermes version​

  • Head to the Publish Tag workflow in the Hermes repo. Click the "Run Workflow" button and input the RN stable version you are targeting (e.g. 0.69.0). You need to have write access to the facebook/hermes repo to do so or ask a Meta employee to help you on this step.

  • Bump the Hermes version on the release branch using this command:

    # Replace <the_hermes_tag> with the tag that will look like 'hermes-2022-07-20-RNv0.70.0-bc97c5399e0789c0a323f8e1431986e207a9e8ba'
    ./packages/react-native/scripts/hermes/bump-hermes-version.js -t <the_hermes_tag>
  • Add and commit the extra file that got created at packages/react-native/sdks/hermes/.hermesversion.

3. Bump monorepo packages​

  • Update packages in the monorepo by running yarn bump-all-updated-packages. Bear in mind that all the package bumps must be on patch level, and be on the minor you are working on. We need to publish the latest package changes so they will be included in RC0. Read more about the script and how they work here.

  • CI will take care of releasing the new versions on npm once you push the changes to the 0.XX-stable branch.

4. Push the branch and test the current changes​

You can now push the branch you created so that others can also start testing:

git push origin 0.69-stable

Before continuing further, follow the testing guide to ensure the 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.

5. Kick off the build of 0.{minor}.0-rc.0​

Once you're done with the testing, you can kick-off the bump and publishing of RC0:

# This will walk you through what version you are releasing
yarn trigger-react-native-release --to-version 0.69.0-rc.0 --token <YOUR_CIRCLE_CI_TOKEN>

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

  • Once you have run that 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.
  • This script runs and commits any changes and triggers a deploy job, build_and_publish_npm_package.

  • Note: Look under "All Branches" to find the publish job. CircleCI does not give a way to search for these jobs.

  • Once complete you should be able to run npm view react-native and verify that under the next tag, the version is the expected release version.

    npm view react-native
    latest: 0.68.1 next: 0.69.0-rc.0 nightly: 0.0.0-f617e022c
  • Hermes artifacts will be uploaded to the Maven repository. It might take ~20 minutes for Maven to process them.

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_RC_0] \
--repo ~/react-native --changelog ~/react-native/

# example against 0.68.2 and 0.69.0-rc.0
npx @rnx-kit/rn-changelog-generator --base v0.68.2 --compare v0.69.0-rc.0 \
--repo ~/react-native --changelog ~/react-native/

Create a pull request of this change to react-native repo and add the Changelog label.

Manually Adjust the Changelog​

At the end of the generated Changelog, there could be two additional sections: the Failed to Parse section and the Unknown section.

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.

The Unknown section is populated with commit that landed without the ## Changelog: entry in the summary.

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 following are a set of heuristic we follow to manually update the changelog:

  • Commit of internal changes can be deleted from the Changelog.
    • Examples: commit on BUCK files or code refactoring that do not change behaviours or interfaces
  • Commit which bumps dependencies should be moved to the Changed section
    • For each dependency, there should be a single entry with the most recent bump. Commits that bumps the dependencies to lower versions can be removed

7. Create a GitHub Release​

  • Create a GitHub Release with this template and check "Pre-Release" checkbox.
- <!-- TODO List out notable picks for this patch -->


To test it, run:

<!-- TODO Update with your version -->

npx react-native init RN069RC0 --version 0.69.0-rc.0


- You can participate in the conversation on the status of this release in the [working group](

- To help you upgrade to this version, you can use the [upgrade helper]( βš›οΈ

- See changes from this release in the [changelog PR](


### Help us testing πŸ§ͺ

<!-- TODO Add the call to action for something specific that we want folks to test -->

Let us know how it went by posting a comment in the [working group discussion](! Please specify with system you tried it on (ex. macos, windows).

**Bonus points:** It would be even better if you could swap things around: instead of using a fresh new app, use a more complex one - or use a different library that is already leveraging the new architecture!
Creating a GitHub Release
Creating a GitHub Release.

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 tracking discussion post​

Create a "Road to [YOUR_MINOR_VERSION]" discussion post in the react-native-releases working group:

<!-- Title: Road to <YOUR_VERSION> -->

The branch cut has happened.

## Notice

<!-- TODO update the version -->

- [Current release candidate: 0.69.0-rc.0][current-release]
- Have an issue with current release candidate? [File an issue][issue-form] and we will triage.
- Have a pick request for this release? Does it fall under our [pick request qualifications][release-faq]? If so please create a PR against the release branch and comment with the PR link
- If you are release testing, copy and fill a [test checklist](/contributing/release-testing#test-checklist).

#### Highlighted Changes in this release

<!-- Add stand-out changes in this release, and link to changelog PR. -->

- Checkout this [Changelog PR][changelog-pr]

## [Release Process][release-processes]

#### Checklist

- [ ] [Changelog PR][changelog-pr]
- [ ] Start a Google doc of blog post for release ([start from this skeleton]( and invite contributors of release highlights to expand
- [ ] Follow up on [release dependencies][release-dependencies]
> When ready to publish stable
- [ ] Ship changelog
- [ ] Ship blog post
- [ ] Prepare typescript PR (see
- [ ] Make PR to `react-native-website` with the new version cut ([see docs](

#### Retrospective Topics

<!-- List out pain points, issues to investigate that are not release-blocking to follow up on -->


## Release Status

### Tracking 0.69.0-rc.1

#### Blocking issues for releasing 0.69.0-rc.1


#### Picks for 0.69.0-rc.1


once an RC is released, wrap this section like so

Tracking 0.69.0-rc.1 (released βœ…)
#### Blocking issues for releasing 0.69.0-rc.1


#### Picks for 0.69.0-rc.1



After creating it, make sure to link it in the relevant GitHub Release you created above, and to pin it in the discussion repo.

10. Verify that Upgrade Helper GitHub action has fired​

11. Broadcast that release candidate is out​

Once all the steps above have been completed, it's time to signal to the community that RC0 is available for testing! Do so in the following channels:

12. Bump minor version of all monorepo packages in main​

The packages in the react-native monorepo must always be one minor version ahead of the latest or RC version (e.g. if you have cut 0.72-stable, main needs to be in 0.73.x. Once you're done with releasing the initial RC0, you should:

  • Create a new branch in react-native from main in your own fork.
  • Run yarn bump-all-updated-packages --release-branch-cutoff to bump the minor versions of all packages.
  • Create a PR targeting main in react-native with the commit created by the previous command.