react/scripts/release
Marco 1d6b1660a2 Fixed typo (#14943) 2019-02-24 09:50:23 -08:00
..
create-canary-commands Add progress bars to longer running async release tasks (#14322) 2018-11-26 09:28:37 -08:00
prepare-canary-commands Updated version incrementing suggestion in release script based on team discussion (#14389) 2018-12-07 09:08:39 -08:00
prepare-stable-commands Release scripts documentation (#14863) 2019-02-15 10:00:43 -08:00
publish-commands Improve pactch release process docs (#14923) 2019-02-22 07:43:18 -08:00
shared-commands Release script clarifies which test fixture failed (#14922) 2019-02-22 07:43:27 -08:00
.gitignore Add progress bars to longer running async release tasks (#14322) 2018-11-26 09:28:37 -08:00
README.md Fixed typo (#14943) 2019-02-24 09:50:23 -08:00
ci-add-build-info-json.js Publish a local release (canary or stable) to NPM (#14260) 2018-11-23 12:37:18 -08:00
ci-update-package-versions.js Publish a local release (canary or stable) to NPM (#14260) 2018-11-23 12:37:18 -08:00
create-canary.js Release scripts documentation (#14863) 2019-02-15 10:00:43 -08:00
package.json Automated fixture tests (#14370) 2018-12-02 11:25:45 -08:00
prepare-canary.js Release scripts documentation (#14863) 2019-02-15 10:00:43 -08:00
prepare-stable.js Release scripts documentation (#14863) 2019-02-15 10:00:43 -08:00
publish.js Publish a local release (canary or stable) to NPM (#14260) 2018-11-23 12:37:18 -08:00
snapshot-test.js Automated fixture tests (#14370) 2018-12-02 11:25:45 -08:00
snapshot-test.snapshot Automated fixture tests (#14370) 2018-12-02 11:25:45 -08:00
theme.js Publish a local release (canary or stable) to NPM (#14260) 2018-11-23 12:37:18 -08:00
utils.js Add progress bars to longer running async release tasks (#14322) 2018-11-26 09:28:37 -08:00
yarn.lock Automated fixture tests (#14370) 2018-12-02 11:25:45 -08:00

README.md

React Release Scripts

The release process consists of several phases, each one represented by one of the scripts below.

A typical release goes like this:

  1. When a commit is pushed to the React repo, Circle CI will build all release bundles and run unit tests against both the source code and the built bundles.
  2. Next the release is published as a canary using the prepare-canary and publish scripts. (Currently this process is manual but might be automated in the future using GitHub "actions".)
  3. Finally, a canary releases can be promoted to stable1 using the prepare-stable and publish scripts. (This process is always manual.)

The high level process of creating releases is documented below. Individual scripts are documented as well:

Note that creating a patch release has a slightly different process than a major/minor release.

Process

Publishing a Canary

Canaries are meant to be lightweight and published often. In most cases, canaries can be published using artifacts built by Circle CI.

To prepare a canary for a particular commit:

  1. Choose a commit from the commit log.
  2. Click the "“✓" icon and click the Circle CI "Details" link.
  3. Copy the build ID from the URL (e.g. the build ID for circleci.com/gh/facebook/react/13471 is 13471).
  4. Run the prepare-canary script with the build ID you found 1:
scripts/release/prepare-canary.js --build=13471

Once the canary has been checked out and tested locally, you're ready to publish it:

scripts/release/publish.js --tags canary

1: You can omit the build param if you just want to release the latest commit as a canary.

Publishing a Stable Release

Stable releases should always be created from a previously-released canary. This encourages better testing of the actual release artifacts and reduces the chance of unintended changes accidentally being included in a stable release.

To prepare a stable release, choose a canary version and run the prepare-stable script 1:

scripts/release/prepare-stable.js --version=0.0.0-5bf84d292

This script will prompt you to select stable version numbers for each of the packages. It will update the package JSON versions (and dependencies) based on the numbers you select.

Once this step is complete, you're ready to publish the release:

scripts/release/publish.js --tags next latest

After successfully publishing the release, follow the on-screen instructions to ensure that all of the appropriate post-release steps are executed.

1: You can omit the version param if you just want to promote the latest canary to stable.

Creating a Patch Release

Patch releases should always be created by branching from a previous release. This reduces the likelihood of unstable changes being accidentally included in the release.

Begin by creating a branch from the previous git tag1:

git checkout -b 16.8.3 v16.8.2

Next cherry pick any changes from master that you want to include in the release:

git cherry-pick <commit-hash>

Once you have cherry picked all of the commits you want to include in the release, push your feature branch and create a Pull Request (so that Circle CI will create a canary):

git push origin 16.8.3

Once CI is complete, follow the regular canary and promote to stable processes.

1: The build-info.json artifact can also be used to identify the appropriate commit (e.g. unpkg.com/react@16.8.3/build-info.json shows us that react version 16.8.3 was created from commit 29b7b775f).

Scripts

create-canary

Creates a canary build from the current (local) Git revision.

This script is an escape hatch. It allows a canary release to be created without pushing a commit to be verified by Circle CI. It does not run any automated unit tests. Testing is solely the responsibility of the release engineer.

Note that this script git-archives the React repo (at the current revision) to a temporary directory before building, so uncommitted changes are not included in the build.

Example usage

To create a canary from the current branch and revision:

scripts/release/create-canary.js

prepare-canary

Downloads build artifacts from Circle CI in preparation to be published to NPM as a canary release.

All artifacts built by Circle CI have already been unit-tested (both source and bundles) but canaries should always be manually tested before being published. Upon completion, this script prints manual testing instructions.

Example usage

To prepare the artifacts created by Circle CI build 12677 you would run:

scripts/release/prepare-canary.js --build=12677

prepare-stable

Checks out a canary release from NPM and prepares it to be published as a stable release.

This script prompts for new (stable) release versions for each public package and updates the package contents (both package.json and inline version numbers) to match. It also updates inter-package dependencies to account for the new versions.

Canary release have already been tested but it is still a good idea to manually test and verify a release before publishing to ensure that e.g. version numbers are correct. Upon completion, this script prints manual testing instructions.

Example usage

To promote the canary release 0.0.0-5bf84d292 (aka commit 5bf84d292) to stable:

scripts/release/prepare-stable.js --version=0.0.0-5bf84d292

publish

Publishes the current contents of build/node_modules to NPM.

This script publishes each public package to NPM and updates the specified tag(s) to match. It does not test or verify the local package contents before publishing. This should be done by the release engineer prior to running the script.

Upon completion, this script provides instructions for tagging the Git commit that the package was created from and updating the release CHANGELOG.

Specify a --dry flag when running this script if you want to skip the NPM-publish step. In this event, the script will print the NPM commands but it will not actually run them.

Example usage

To publish a release to NPM as both next and latest:

scripts/release/publish.js --tags next latest