From ce969f92c3cdc7978b69a57d5a2d2e9dd68eeba6 Mon Sep 17 00:00:00 2001 From: Teddy Katz Date: Wed, 28 Jun 2017 00:41:58 -0700 Subject: [PATCH] Docs: add guidelines for patch release communication (fixes #7277) (#8823) This updates the release documentation to describe how to use release issues to communicate releases to the team. --- docs/maintainer-guide/releases.md | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/docs/maintainer-guide/releases.md b/docs/maintainer-guide/releases.md index cf92d7f561b..4d9f0958751 100644 --- a/docs/maintainer-guide/releases.md +++ b/docs/maintainer-guide/releases.md @@ -16,6 +16,10 @@ A two-person release team is assigned to each scheduled release. This two-person The two-person team should seek input from the whole team on the Monday following a release to double-check if a patch release is necessary. +## Release Communication + +Each scheduled release should be associated with a release issue ([example](https://github.com/eslint/eslint/issues/8138)). The release issue is the source of information for the team about the status of a release. Be sure the release issue has the "release" label so that it's easy to find. + ## Process On the day of a scheduled release, the release team should follow these steps: @@ -27,10 +31,10 @@ On the day of a scheduled release, the release team should follow these steps: * Small bug fixes written by a team member. 1. Log into Jenkins and schedule a build for the "ESLint Release" job. 1. Wait for the "ESLint Release" job to complete. -1. Update the release blog post with a "Highlights", including new rules and anything else that's important. -1. Make release announcement in the chatroom. -1. Make release announcement on Twitter. -1. Remind the team not to merge anything other than documentation changes and bug fixes. +1. Update the release blog post with a "Highlights" section, including new rules and anything else that's important. +1. Make a release announcement in the public chatroom. +1. Make a release announcement on Twitter. +1. Make a release announcement on the release issue. Document any problems that occurred during the release, and remind the team not to merge anything other than documentation changes and bug fixes. Leave the release issue open. On the Monday following the scheduled release, the release team needs to determine if a patch release is necessary. A patch release is considered necessary if any of the following occurred since the scheduled release: @@ -39,7 +43,9 @@ On the Monday following the scheduled release, the release team needs to determi The patch release decision should be made as early on Monday as possible. If a patch release is necessary, then follow the same steps as the scheduled release process. -After the patch release has been published (or no patch release is necessary), inform the team that they can start merging in changes again. +In rare cases, a second patch release might be necessary if the release is known to have a severe regression that hasn't been fixed by Monday. If this occurs, the release team should announce the situation on the release issue, and leave the issue open until all patch releases are complete. However, it's usually better to fix bugs for the next release cycle rather than doing a second patch release. + +After the patch release has been published (or no patch release is necessary), close the release issue and inform the team that they can start merging in semver-minor changes again. ## Emergency Releases