{"body":"","patch":"diff --git a\/scripts\/release\/README.md b\/scripts\/release\/README.md\nindex f8f2cc7fa5..3deb2ffeeb 100644\n--- a\/scripts\/release\/README.md\n+++ b\/scripts\/release\/README.md\n@@ -5,7 +5,7 @@ The release process consists of several phases, each one represented by one of t\n A typical release goes like this:\n 1. When a commit is pushed to the React repo, [Circle CI](https:\/\/circleci.com\/gh\/facebook\/react\/) will build all release bundles and run unit tests against both the source code and the built bundles.\n 2. Next the release is [**published as a canary**](#publishing-a-canary) using the [`prepare-canary`](#prepare-canary) and [`publish`](#publish) scripts. (Currently this process is manual but might be automated in the future using [GitHub \"actions\"](https:\/\/github.com\/features\/actions).)\n-3. Finally, a canary releases can be [**promoted to stable**](#publishing-a-stable-release) using the [`prepare-stable`](#prepare-stable) and [`publish`](#publish) scripts. (This process is always manual.)\n+3. Finally, a canary releases can be [**promoted to stable**](#publishing-a-stable-release)^{1<\/sup> using the [`prepare-stable`](#prepare-stable) and [`publish`](#publish) scripts. (This process is always manual.)\n \n The high level process of creating releases is [documented below](#process). Individual scripts are documented as well:\n * [`create-canary`](#create-canary)\n@@ -13,6 +13,8 @@ The high level process of creating releases is [documented below](#process). Ind\n * [`prepare-stable`](#prepare-stable)\n * [`publish`](#publish)\n \n+^{Note that [**creating a patch release**](creating-a-patch-release) has a slightly different process than a major\/minor release.<\/sup>\n+\n # Process\n \n ## Publishing a Canary\n@@ -53,8 +55,36 @@ Once this step is complete, you're ready to publish the release:\n scripts\/release\/publish.js --tags next latest\n ```\n \n+After successfully publishing the release, follow the on-screen instructions to ensure that all of the appropriate post-release steps are executed.\n+\n ^{1: You can omit the `version` param if you just want to promote the latest canary to stable.<\/sup>\n \n+## Creating a Patch Release\n+\n+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.\n+\n+Begin by creating a branch from the previous git tag^{1<\/sup>:\n+\n+```sh\n+git checkout -b 16.8.3 v16.8.2\n+```\n+\n+Next cherry pick any changes from master that you want to include in the release:\n+\n+```sh\n+it cherry-pick \n+```\n+\n+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):\n+\n+```sh\n+git push origin 16.8.3\n+```\n+\n+Once CI is complete, follow the regular [**canary**](#publishing-a-canary) and [**promote to stable**](#publishing-a-stable-release) processes.\n+\n+^{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](https:\/\/unpkg.com\/react@16.8.3\/build-info.json) shows us that react version 16.8.3 was created from commit [`29b7b775f`](https:\/\/github.com\/facebook\/react\/commit\/29b7b775f)).<\/sup>\n+\n # Scripts\n \n ## `create-canary`\ndiff --git a\/scripts\/release\/publish-commands\/print-follow-up-instructions.js b\/scripts\/release\/publish-commands\/print-follow-up-instructions.js\nindex 08d97465d1..41e1d4544b 100644\n--- a\/scripts\/release\/publish-commands\/print-follow-up-instructions.js\n+++ b\/scripts\/release\/publish-commands\/print-follow-up-instructions.js\n@@ -7,6 +7,7 @@ const {existsSync} = require('fs');\n const {readJsonSync} = require('fs-extra');\n const {join} = require('path');\n const theme = require('..\/theme');\n+const {execRead} = require('..\/utils');\n \n const run = async ({cwd, packages, tags}) => {\n \/\/ All packages are built from a single source revision,\n@@ -20,6 +21,10 @@ const run = async ({cwd, packages, tags}) => {\n `${cwd}\/build\/node_modules\/react\/package.json`\n );\n \n+ const branch = await execRead('git branch | grep \\\\* | cut -d \" \" -f2', {\n+ cwd,\n+ });\n+\n clear();\n \n if (tags.length === 1 && tags[0] === 'canary') {\n@@ -64,9 +69,19 @@ const run = async ({cwd, packages, tags}) => {\n \n console.log();\n console.log(\n- theme`{header Don't forget to update and commit the }{path CHANGELOG}`\n+ theme`{header Don't forget to also update and commit the }{path CHANGELOG}`\n );\n \n+ if (branch !== 'master') {\n+ console.log();\n+ console.log(\n+ theme`{header Don't forget to cherry-pick any updated error codes into the} {path master} {header branch}.`\n+ );\n+ console.log(\n+ theme`Else they will not be properly decoded on {link reactjs.org}.`\n+ );\n+ }\n+\n \/\/ Prompt the release engineer to tag the commit and update the CHANGELOG.\n \/\/ (The script could automatically do this, but this seems safer.)\n console.log();\n@@ -104,6 +119,18 @@ const run = async ({cwd, packages, tags}) => {\n );\n }\n }\n+\n+ \/\/ Updating reactjs.org accomplishes two things:\n+ \/\/ (1) It ensures our Gatsby error codes plugin runs with the latest error codes.\n+ \/\/ (2) It keeps the React version shown in the header up to date.\n+ console.log();\n+ console.log(\n+ theme.header`Once you've pushed changes, update the docs site.`\n+ );\n+ console.log(\n+ 'This will ensure that any newly-added error codes can be decoded.'\n+ );\n+\n console.log();\n }\n };\n","commit":{"subject":"Improve pactch release process docs (#14923)","authoredAt":"2019-02-22T07:43:18-08:00","authorName":"Brian Vaughn","revision":"f708f9e307e5d2579a019b7d53cb06bac63d6d44","shortRevision":"f708f9e307","authorEmail":"brian.david.vaughn@gmail.com"},"parents":["f99fca3cb28e1fbd87e0b647ac43959add290be7"],"files":[{"status":"M","path":"scripts\/release\/README.md"},{"status":"M","path":"scripts\/release\/publish-commands\/print-follow-up-instructions.js"}]}}}}}}

dillon1000/react

Files changed