-
Notifications
You must be signed in to change notification settings - Fork 1.1k
How to promote a release
Find a commit corresponding to a published nightly build. These commits have a message starting with "applying package updates", such as this one. This build should use a version of react-native close to the one chosen as the basis of the stable branch of RN core.
Check out this build locally. E.g. git checkout c9f39b4
Run yarn promote-release --release preview --rnVersion 0.xx
This script will locally create a stable branch and update various configuration files and manifests in the repo to work correctly with the stable branch. After running the tool, a new 0.xx-stable
branch should be locally checked out with changes committed.
At this point the branch is still depending on a nightly build of react-native. Dependencies should be upgraded to the Facebook RC build closest to nightly build (e.g. 0.63.0-rc.0). This update may or may not introduce new changes. A quick way to check is to compare branches on the facebook/react-native Github repo and look for any commits before the first RC version. E.g. for 0.63, there were 5 commits cherry-picked into 0.63-stable before the first RC.
This step can be automated by using integrate-rn
, such as by running yarn integrate-rn 0.64.0-rc.1
.
Once we are using a stable react-native
build, we should update react-native
peer dependencies for react-native-windows
and @office-iss/react-native-win32
to allow a range (start with ^
) instead of requiring a fixed version.
Normal PRs to the main
branch run checks against a subset of the build configurations run by the daily CI pipeline. This improves code velocity in main
, but also risks build breaks in the unchecked configurations, which, if not addressed, risks publishing broken canary
releases.
To prevent breaking stable builds, PRs to stable branches must be expanded to build all of the configurations normally built by CI. This is done by manually updating the buildMatrix
object parameters in the pipeline yml
files under /.ado/jobs/
:
- Look for the
buildMatrix
parameters, which typically contain two child nodes:BuildEnvironment: PullRequest
andBuildEnvironment: Continuous
- Replace the
Matrix
underBuildEnvironment: PullRequest
with theMatrix
fromBuildEnvironment: Continuous
(leave out any entries that set the UseExperimentalWinUI3 flag) - Commit your changes to your local branch.
- Skip the change file check by adding
npx beachball check --branch origin/$(BeachBallBranchName) --verbose 2>&1 | Tee-Object -Variable beachballOutput
in setup.yml. See this commit as an example: https://github.com/microsoft/react-native-windows/commit/11543bb94420586be0523b4b49d0b8e425939a9d
Push your results upstream to the microsoft/react-native-windows
repo as a temporary branch (e.g. assuming you've set up microsoft/react-native-windows
as the upstream
remote, and you want a temporary branch preview-0.64-test
, use git push -u upstream 0.64-stable:preview-0.64-test
). Manually run the PR pipeline against the test branch to detect any issues. It is expected that the "Check for change files" step will fail for manually triggered runs, and any missed test coverage should be run locally.
⚠ Make sure your temporary branch doesn't match the wildcard
*-stable
Manual validation should be performed before publishing the build to ensure there aren't any showstopper issues. The validation performed is outside the scope of this document.
Once ready, re-push your local branch directly to the microsoft/react-native-windows
repo with the correct name (e.g. assuming the upstream
remote as above, use git push -u upstream 0.64-stable
). The Publish pipeline can now be manually scheduled to run on that branch for the release.
To schedule the automatic, daily CI for the branch, and the new branch to the Scheduled Triggers for the CI pipeline.
To schedule the automatic, weekly publish for the branch, add the new branch to the Scheduled Triggers for the Publish pipeline.
To prevent older branches from being published as latest
we need to change the tag they publish as. To do that:
- Check out the current branch for
latest
(the one before preview) (i.e.git checkout 0.XX-stable
) - Make sure your branch is up-to-date with the
microsoft/react-native-windows
repo - Create a new branch for the PR (i.e.
git checkout -b promoteXX
) - Run
yarn promote-release --release legacy --rnVersion 0.XX
- Create a PR with the generated commits to the
latest
branch (i.e.git push -u origin promoteXX
) - After the PR is merged, wait for (or kick off) a new Publish run for the
0.XX-stable
branch
- Check out the current branch for
preview
(i.e.git checkout 0.YY-stable
) - Make sure your branch is up-to-date with the
microsoft/react-native-windows
repo - Ensure there are no pending changes to be published (changefiles in the changes directory).
⚠ Any changefiles targeting preview that slip through after promotion will have the wrong change type and prevent publishing changes
Same as above, we want to do a final check to see if there are any issues that may have slipped in.
- Create a new branch for the PR (i.e.
git checkout -b promoteYY
) - Run
yarn promote-release --release latest --rnVersion 0.YY
- Integrate the final published RN version (yarn integrate-rn 0.YY.0 and any commands in wiki integration instructions)
- Create a PR with the results (i.e.
git push -u origin promoteYY
) - After the PR is merged, wait for (or kick off) a new Publish run for the
0.YY-stable
branch
Same as above, we want to do a final check to see if there are any issues that may have slipped in.