Release Checklist

Overview

This document describes the checklist to publish a release via GitHub workflow.

See Release Management for the overall process of versioning and support.

Note

The maintainers may periodically update this checklist based on feedback.

Releasing is a two-step process for voting on a specific release, and cutting the release.

Determine a SemVer2-valid version prefixed with the letter v for release. For example, v1.0.0-alpha.1, v1.0.0.
Make sure the dependencies in go.mod file are expected by the release.
After updating go.mod file, run go mod tidy to ensure the go.sum file is also updated with any potential changes.
Determine the commit to be tagged and released.
Create an issue for voting with title similar to "vote: tag v1.0.0-alpha.1 with the proposed commit. (see Issue #204
Request a 👍or 👎from each maintainer, requesting details if they voted against, and opening a corresponding issue.
Wait a max of 2 weeks for the vote pass, or sooner if a majority of maintainers approve.

Select [Draft a new release]
[Choose a tag]: Create a new tag based on Alpha, RC or a final release: (v1.0.0-alpha.1, v1.0.0-rc.1, v1.0.0).
[Target]: Select the voted commit in "Recent Commits".
[Previous Tag]: Select the previous corresponding release.
1. For alpha and rc releases, select the previous release within that release band (rc.1, select the latest alpha release).
2. For final releases, select the previous full release: (v1.3.0, selects v1.1.0)
[Generate Release Notes]: Edit for spelling and clarity.
[Release title] Set to the same value as the tag and voted issue.
[Set as a pre-release]: Set if the release is an alpha or rc.
Do not set for final release.
[Set as the latest release]: To bring focus to the latest, always check this box.
Announce the release in the community.