Release Process

The following will describe the steps shown in the diagram.

Pre-requisites

• Write access to react-native repo
• Write access for react-native-community/releases (this repo) to label, update issues.
• If testing, follow pre-requisites for testing

Steps

1. Branch cut

• Create the stable branch in react-native repo with the appropriate name. Usually 0.X-stable

  git checkout main
  git pull
  git checkout -b 0.42-stable
  git push origin 0.42-stable # your remote alias might be different

• Create a changelog of the release branch. Instructions here. Example of 0.66 changelog
• Create a new tracking issue and update to new target release. This is now where we’ll track incoming cherry-pick requests and update to any release-blocking issues. See 0.66 issue as reference
• Ask the contributors involved in the highlights of this version to start preparing a blog-post to accompany the release. Can use Google Doc for collaboration at first, then convert to PR against react-native-website

1a. Alert dependencies about branch cut

• See dependencies and coordinate if these projects need to release a new version.
  • ex. Hermes will probably need another release.

2. Test

• See instructions for release testing

→ b. release-blocking issue from test

• See definition: What qualifies as release blocking?

3. Create release issue

• Ask people to create release-blocking issues when something comes up.
• Add the Needs: React Native Attention label if needs FB attention.

→ c. fixes, cherry-pick in

• Qualified pick requests made on the tracking issues, fixes from release issues get cherry-picked in.

  react-native(rc-branch)$ git cherry-pick <hash>

4. Publish Release Candidate

• On your local checkout of the release branch, make sure you have no local changes and run scripts/bump-oss-version .
  • This script will update the version, commit, and push those changes to the remote branch.
  • It will also create a tag of the version you supply.

    react-native$ ./scripts/bump-oss-version.js -v 0.X.0-rc.Y # ex. 0.66.0-rc.2

• Once those changes have been pushed, CircleCI will start a job to publish the release via npm.
  • 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 next is expected release version

    $ npm view react-native
    ....
    dist-tags:
    latest: 0.65.1            next: 0.66.0-rc.2         nightly: 0.0.0-f617e022c

• After publishing, create a “Github Release”.

  • Select the tag you just created

  • Check the pre-release checkbox.

  • You can copy the template used for this release candidate patch

    
• After creating Github release, update the upgrade-helper
• Broadcast that the release candidate is out
  • On tracking issue
  • Discord #releases channel
  • Twitter?

4a. Follow-up with dependencies

• See dependencies and make sure their releases are picked in.

→ e. release-blocking issues from community

• Make sure these are qualified blockers

→ f. no release-blocking issues

• See When do we go to stable?

5. Publish Release

Before publishing release make sure:

• Changelog PR is ready to land
• Blog post is drafted and looks good

Publish

• Publish the stable branch as a stable version. (Similar to step 4, only version change to stable)

    react-native$ ./scripts/bump-oss-version.js -v 0.X.0 # ex. 0.66.0
   
    react-native$ npm view react-native # verify

• Create a patch release issue to track issues in the stable release.
• Create a Github Release (similar to step 4) but no longer a Pre-release. Example Github release
• Upgrade the upgrade helper

5a. Follow-up with dependencies

• Make a PR with the new release of the website documentation by following the steps in their guide, then merge it so it will show show the new version as the currently available version.
  • You can verify that it's defaulting correctly by checking the website-config file.

6 Create a post-release issue

• Point people to this form (TODO)

7. Test

• Is the testing any different for patch releases (TODO)

8. Publish Release Patch

• Anything different than #4?