Release v6.14.18

[ruyadorno]

6.14.18 (2022-12-21)

DEPENDENCIES

• f55bd65da [email protected]
• cd4894696 [email protected]
• 023d7e96b [email protected]
• dd2811c0b [email protected]:3
• e21b6ebd9 [email protected]
• 2bec581c6 [email protected]
• 273485157 [email protected]
• 720f8ae5e [email protected]
• 5f1200e33 [email protected]:0
• 58b74a38b [email protected]
• 4b609655f [email protected]
• 14c7a1a85 [email protected]
• 06d9cefc4 [email protected]
• 1d2da355c [email protected]
• 22eda3a26 [email protected]
• b77a7f1b0 [email protected]
• de37398af [email protected]
• 196650baa [email protected]
• 3218c16b5 [email protected]
• 0f5d57919 [email protected]
• 43ed5c23b [email protected]
• 31b51c564 [email protected]
• 209a79d1f [email protected]
• 4778a8d95 [email protected]
• 8b357e558 [email protected]
• d3e7eed13 [email protected]

[lukekarrys]

Historical release notes for reference

Cutting the release

Each branch's release manager follows this procedure:

1. The release manager ensures that all tests are passing for the release branch (usually release-next or release-next-<n>).

2. The release manager updates the changelog with salient changes for that release, calling out any breaking changes. You can get a head start on the changelog by running scripts/gen-changelog, which will do its machine best to generate a changelog for you and stick it at the top of CHANGELOG.md. It's not a very smart script though, so you'll still need to edit the result.

3. The release manager gets a CLI team member to review the release notes for content and style.

4. The release manager runs npm version <version> on the branch. If it's a new patch or minor version, it should be X.Y.Z-next.0. If it's a patch to an existing prerelease, increment the number. The git release tags are always signed with GnuPG by a npm core team member. (More on setting up GPG with Git.)

5. The release manager runs make publish on the branch. This:

   1. Ensures that the docs have been built correctly.
   2. Ensures that all changes and tags have been pushed to the appropriate branch on GitHub.
   3. Publishes npm to the registry, setting the release tag to vX.Y-next (not latest, for reasons described above).
   4. NOTE: make sure you have github and npm write permissions!

6. The release manager runs npm dist-tag set npm@<new-version> next (or, next-<n> if doing a prerelease for a different major version line)

7. The release manager cleans up the vX.Y-next that was generated as part of the publish process, using npm dist-tag rm npm vX.Y-next.

8. From the docs repo, pull down any changes that have been made to content in the docs repo and then push to trigger an automatic update of the CLI documentation :

   git fetch --all
   git reset --hard origin/latest
   git commit -avm "emptiness" --allow-empty

9. Enter your GPG key.

   git push origin +latest:deploy-staging
   git push origin +latest:deploy-production

10. Post the release notes to Github Releases. Make sure to remove extra newlines from the original, to preserve text flow in browsers.

11. Post the release notes to npm.community #announcements.

12. The release manager tweets about the new release!

13. Post a link on the npmjs tumblog.

[lukekarrys]

Reopening as #5989