Skip to content

Release Guide

Jump to bottom
Chiara Mooney edited this page Oct 4, 2023 · 4 revisions

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

  • Update preview release notes with any changes from cherry-picked PRs
  • Update samples
  • Update React Native Gallery
  • Publish React Native Gallery
  • Promote preview build to latest using wiki instructions
  • Update GitHub release notes to use manually curated notes instead of a changelog
  • Update website
  • Send out internal release announcement
  • Update CI to use /apiVersion 0.XX -- After Website Updated
  • Ensure Accessibility is tested through updated Gallery
Clone this wiki locally