Merge pull request containerd#8250 from dmcgowan/update-release-process

Update release process after 1.7

Author: Maksym Pavlenko

releases/README.md

@@ -11,24 +11,31 @@ verified:
 
 1. Create release pull request with release notes and updated versions.
 
-   1. Compile release notes detailing features added since the last release and
+   1. Review all pull requests merged into the release. For any pull request
+      that should be highlighted in the release notes, add the appropriate
+      `impact/*` and `area/*` labels. Update the title to match the style used
+      in release notes. Normally the titles are short descriptions starting with
+      a present tense verb and optionally prepended with square brackets section
+      which usually includes release branch.
+
+   2. Compile release notes with summary of changes since the last release and
       add release template file to `releases/` directory. The template is defined
       by containerd's release tool but refer to previous release files for style
       and format help. Name the file using the version, for rc add an `-rc` suffix.
       When moving from rc to final, the rc file may just be renamed and updated.
       See [release-tool](https://github.com/containerd/release-tool)
 
-   2. Update the version file at `https://github.com/containerd/containerd/blob/main/version/version.go`
+   3. Update the version file at `https://github.com/containerd/containerd/blob/main/version/version.go`
 
-   3. Update RELEASES.md to refer to the new release and dates.
+   4. (major/minor release only) Update RELEASES.md to refer to the new release and dates.
 
-   4. Update the `.mailmap` files for commit authors which have multiple email addresses in the commit log.
+   5. Update the `.mailmap` files for commit authors which have multiple email addresses in the commit log.
       If it is not clear which email or name the contributor might want used in the release notes, reach
       out to the contributor for feedback. NOTE: real names should be used whenever possible. The file is
       maintained by manually adding entries to the file.
       - e.g. `Real Name <[email protected]> Other Name <[email protected]>`
 
-   5. Before opening the pull request, run the release tool using the new release notes.
+   6. Before opening the pull request, run the release tool using the new release notes.
       Ensure the output matches what is expected, including contributors, change log,
       dependencies, and visual elements such as spacing. If a contributor is duplicated,
       use the emails outputted by the release tool to update the mailmap then re-run. The
@@ -41,7 +48,8 @@ verified:
       expects tags to be formatted as `vx.y.z[-rc.n]`.
 
    2. Generate release notes (using a temp file may be helpful).
-      - e.g. `release-tool -l -d -n -t v1.0.0 ./releases/v1.0.0.toml > /tmp/v1.0.0-notes`
+      - e.g. `release-tool -r -g -d -n -t v1.0.0 ./releases/v1.0.0.toml > /tmp/v1.0.0-notes`
+      - if release notes are too long, such as for major/minor releases, add `--skip-commits` option
 
    3. Create tag using the generated release notes.
       - e.g. `git tag --cleanup=whitespace -s v1.0.0 -F /tmp/v1.0.0-notes`
@@ -51,21 +59,27 @@ verified:
 3. Push tag and Github release
 
    1. Push the tag to `[email protected]:containerd/containerd.git`.
-      NOTE: this will kick off CI building of the release binaries.
+      NOTE: this will kick off CI to prepare the Github release and binaries.
 
-   2. Create the Github release using the `Tag version` which was just pushed. Use the first
-      line outputted from the release tool as the `Release title` and the remainder of the
-      output for the description. No alteration of the release output should be needed.
-      Ensure `pre-release` is checked if an `-rc`.
-      NOTE: This should be done immediately after pushing the tag, otherwise CI may create the release
-      when the binaries are pushed.
+   2. Verify release job has started in the actions tab and wait for release job to complete
+      successfully. If the job fails, attempt to restart it. If the job continuously fails,
+      delete the tag from GitHub as soon as possible and fix the issue before restarting the
+      release process.
 
-   3. Check CI has completed and uploaded the binaries. Remove any binaries which get
-      uploaded but are not intended as part of the release (e.g. Darwin binaries).
+   3. Check the Github release, ensure the content matches what is expected and all the
+      release binaries are included.
 
-4. Update [`config.toml`](https://github.com/containerd/containerd.io/blob/f827d53826a426cb48f24cc08e43cc8722ad6d01/config.toml#L35) with latest release in the [containerd/containerd.io project](https://github.com/containerd/containerd.io); open PR to
+4. (major/minor release only) Create `release/x.y` branch from tag and push to `[email protected]:containerd/containerd.git`.
+
+5. (patch release only) Update RELEASES.md in main branch to refer to the new patch release.
+
+6. (major/minor release only) Create `cherry-pick/x.y.x` and `cherry-picked/x.y.x` labels
+
+7. Close any milestones associated with the release.
+
+8. Update [`config.toml`](https://github.com/containerd/containerd.io/blob/f827d53826a426cb48f24cc08e43cc8722ad6d01/config.toml#L35) with latest release in the [containerd/containerd.io project](https://github.com/containerd/containerd.io); open PR to
    force website downloads update.
 
-5. Update Kubernetes test infrastructure to test against any new release branches, see example from https://github.com/kubernetes/test-infra/pull/25476
+9. Update Kubernetes test infrastructure to test against any new release branches, see example from https://github.com/kubernetes/test-infra/pull/25476
 
-6. Promote on Slack, Twitter, mailing lists, etc
+10. Promote on Slack, Twitter, mailing lists, etc