Release Guide

Cadence

React Native aims to release 3-4 versions of React Native each year. Our goal is to release on time with upstream, ideally aiming for a one week turnaround time between the releases of React Native and React Native Windows.

Our release process should begin right after React Native has published their first release candidate for the next release (v0.XX.0-rc.1).

Process

Every release should have a release driver. For React Native Windows, @chiaramooney is the current release driver. The release driver is responsible for making sure that all release steps are delegated and carried out, monitoring the release for quality, and keeping the release on pace with upstream.

At the start of the release cycle, the release driver should create a new 0.XX Release Status issue. This issue can be created by copying the content from the previous 0.XX Release Status issue. It can also be found at the bottom of this document.

Draft GitHub Release Notes from Commit Log

Release notes should contain descriptions of all key changes in the platform. Our release notes are broken down into sections for reliability, new features, other, and breaking changes. If we have made significant changes to one section of the platform, we will also add a dedicated section to call out those changes. Change descriptions should include a summary of the change and a link to the change's commit. Recently, we added a section to our PR Template which includes an option to enter a change description. Use this description in the release notes, if it is specified.

The release notes should also include the date range for the React Native and React Native Windows commits included in the release.

The release notes should be posted under GitHub Releases for the repository once the first v0.XX.0-preview.0 has been published. Before posting, the release notes should be shared with the team to confirm all changes were effectively captured.

Creating a Release Preview

Instructions for how to create a release preview can be found here: wiki instructions. A v0.XX-stable branch will be produced at the end of these steps. CI pipelines in the repo will then publish all branches with this syntax to npm.

Finalizing Release Contents

The release driver should walk through the current set of open issues targeted for the next release and determine which issues the release should hold for and which issues can be moved to the next milestone. This also includes monitoring for backports and making sure all changes attempted to backport make sense in this release.

Validate Release

There are a number of steps we take to validate the release. The first is via updating React Native Gallery to the new release preview and confirming that the app works and renders as expected. See wiki instructions for more information. The next step is to check the CI runs in react-native-windows-samples confirm that the sample apps are updating and running as expected on the new preview. Next you'll want to manually validate a few scenarios in the release. See wiki instructions for more information.

As React Native releases more release candidates you'll want to update the React Native Windows release preview to use those new versions. Manual validation should be performed after these upgrades to confirm that incoming changes from upstream did not break the package.

Publishing a New Release

To move the release preview to latest, we follow these instructions: wiki instructions. Release announcements are sent out via Teams, Discord, and Twitter. All sample apps are then moved to the new release and published to GitHub and/or the Microsoft Store. Our website is also updated to reflect the correct documentation for the new release.

Release Checklist

This checklist contains the set of tasks that should be completed before every release. An issue should be created prior to the start of the work on the next release with the contents below. The issue should then be pinned in the repo for easy discoverability. Each task should have an assignee. This should be indicated by adding the GitHub username of the assigned dev next to the task like this: (<@username>).

Before Preview

Draft GitHub release notes from commit log
Promote canary build to preview using wiki instructions
Push build to stable branch
Enable CI schedule for new branch of CI pipeline
- Update dashboard @ms with an entry for CI ${version}
- Add release schedule for the new stable branch of publish pipline
- Update dashboard @microsoft with an entry for Publish ${version}
Update GitHub release notes to use manually curated notes instead of a changelog
Post release notes internally

After Preview

Move most issues targeting current release
Test updated gallery app using wiki instructions
Check CI Runs for Upgrading Sample Apps (@jonthysell )
Snap Hermes-Windows release
Do a pass on API Docs using wiki instructions
Integrate any applicable patch/prerelease releases for React Native

Before Release

Ensure doc issues are addressed
Promote latest build to legacy using wiki instructions

Release

Provide feedback

Saved searches

Use saved searches to filter your results more quickly