Packages: Further clarify the npm publishing process (#30733)

* Packages: Further clarify the npm publishing process

* Update packages/README.md

docs/contributors/code/release.md

@@ -47,6 +47,7 @@ This will cause the new version to be available to users of WordPress all over t
 You should check that folks are able to install the new version from their Dashboard.
 
 Once released, all that's left to do is writing a release post on [make.wordpress.org/core](https://make.wordpress.org/core/). You can find some tips on that below.
+
 ### Writing the Release Notes and Post
 
 The release notes draft is auto-generated by a script that looks for pull requests for the current milestone, and groups them by pull request label.
@@ -77,6 +78,7 @@ If a bug is found in a release candidate and a fix is committed to `trunk`, we s
 3. When done, push the changes to GitHub: `git push`.
 
 If you decide that the fixes deserve another release candidate before the stable version is published, create one by following the instructions above. Let other contributors know that a new release candidate has been released in the [`#core-editor` channel](https://wordpress.slack.com/messages/C02QB2JS7).
+
 ## Packages Releases to npm and WordPress Core Updates
 
 The Gutenberg repository mirrors the [WordPress SVN repository](https://make.wordpress.org/core/handbook/about/release-cycle/) in terms of branching for each SVN branch, a corresponding Gutenberg `wp/*` branch is created:
@@ -121,7 +123,7 @@ Finally, now that the npm packages are ready, a patch can be created and committ
 
 The following workflow is needed when bug fixes or security releases need to be backported into WordPress Core. This can happen in a few use-cases:
 
--   During the `beta` and the `RC` period of the WordPress release cycle.
+-   During the `RC` period of the WordPress release cycle when `wp/X.Y` (example `wp/5.7`) branch for the release is already present.
 -   For WordPress minor releases and WordPress security releases (example `5.1.1`).
 
 1. Check out the relevant WordPress major branch (If the minor release is 5.2.1, check out `wp/5.2`).
@@ -133,12 +135,12 @@ Now, the branch is ready to be used to publish the npm packages.
 
 1. Check out the WordPress branch used before (Example `wp/5.2`).
 2. `git pull`.
-3. Run the [package release process] but when asked for the version numbers to choose for each package, (assuming the package versions are written using this format `major.minor.patch`) make sure to bump only the `patch` version number. For example, if the last published package version for this WordPress branch was `5.6.0`, choose `5.6.1` as a version.
+3. Run the `npm run publish:patch` command (see more in [package release process]) but when asked for the version numbers to choose for each package, (assuming the package versions are written using this format `major.minor.patch`) make sure to bump only the `patch` version number. For example, if the last published package version for this WordPress branch was `5.6.0`, choose `5.6.1` as a version.
 
 **Note:** For WordPress `5.0` and WordPress `5.1`, a different release process was used. This means that when choosing npm package versions targeting these two releases, you won't be able to use the next `patch` version number as it may have been already used. You should use the "metadata" modifier for these. For example, if the last published package version for this WordPress branch was `5.6.1`, choose `5.6.1+patch.1` as a version.
 
-3. Update the `CHANGELOG.md` files of the published packages with the new released versions and commit to the corresponding branch (Example `wp/5.2`).
-4. Cherry-pick the CHANGELOG update commits into the `trunk` branch of Gutenberg.
+3. Optionally update the `CHANGELOG.md` files of the published packages with the new released versions and commit to the corresponding branch (Example `wp/5.2`).
+4. Cherry-pick the CHANGELOG update commits, if any, into the `trunk` branch of Gutenberg.
 
 Now, the npm packages should be ready and a patch can be created and committed into the corresponding WordPress SVN branch.
 
@@ -213,7 +215,7 @@ Now that the changes have been committed to the `wp/trunk` branch and the Travis
     > @wordpress/scripts
     > lerna success found 3 packages ready to publish
     > ```
-2. Run the [package release process] but when asked for the version numbers to choose for each package use the versions you made note of above when updating each packages `CHANGELOG.md` file.
+2. Run the `npm run publish:prod` command (see more in [package release process]) but when asked for the version numbers to choose for each package use the versions you made note of above when updating each packages `CHANGELOG.md` file.
     > Truncated example of publishing process output
     >
     > ```

packages/README.md

@@ -176,7 +176,7 @@ If you are publishing new versions of packages, note that there are versioning r
 
 ## Releasing Packages
 
-Lerna automatically releases all outdated packages. To check which packages are outdated and will be released, type `npm run publish:check`.
+Lerna automatically releases all outdated packages. To check which packages are outdated and will be released, type `npm run publish:check` from the branch that keeps the code for a given `wp/X.Y` release type (example `wp/5.7`).
 
 If you have the ability to publish packages, you _must_ have [2FA enabled](https://docs.npmjs.com/getting-started/using-two-factor-authentication) on your [npm account][npm].
 
@@ -198,36 +198,39 @@ You can check your package configs by running `npm run lint-pkg-json`.
 
 ### Development Release
 
-Run the following command to release a dev version of the outdated packages.
+Run the following commands from the `trunk` branch to publish to npm (with a `next` dist tag) a development version of the packages.
 
 ```bash
-npm run publish:dev
+npm install
+./bin/plugin/cli.js npm-next
 ```
 
-Lerna will ask you which version number you want to choose for each package. For a `dev` release, you'll more likely want to choose the "prerelease" option. Repeat the same for all the outdated packages and confirm your version updates.
-
-Lerna will then publish to [npm], commit the `package.json` changes and create the git tags.
+See more details in [Development Releases](/docs/contributors/code/release.md#development-releases) section of the Gutenberg release process documentation.
 
 ### Production Release
 
-To release a production version for the outdated packages, run the following command:
+To release a production version for the outdated packages, run the following commands from the `trunk` branch:
 
 ```bash
-npm run publish:prod
+npm install
+./bin/plugin/cli.js npm-latest
 ```
 
-Choose the correct version based on `CHANGELOG.md` files, confirm your choices and let Lerna do its magic.
+See more details in [Synchronizing WordPress Trunk](/docs/contributors/code/release.md#synchronizing-wordpress-trunk) section of the Gutenberg release process documentation.
 
 ### Legacy Patch Release
 
-To release a patch for the older major or minor version of packages, run the following command:
+To release a patch for the older major or minor version of packages, run the following commands from the corresponding `wp/X.Y` (example `wp/5.7`) release branch:
 
 ```bash
+npm install
 npm run publish:patch
 ```
 
 This is usually necessary when adding bug fixes or security patches to the earlier versions of WordPress. This will publish only a patch version of the built packages. This is useful for backpublishing certain packages to WordPress.
 
+See more details in [Minor WordPress Releases](/docs/contributors/code/release.md#minor-wordpress-releases) section of the Gutenberg release process documentation.
+
 ## TypeScript
 
 The [TypeScript](http://www.typescriptlang.org/) language is a typed superset of JavaScript that compiles to plain JavaScript.