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, rungo mod tidy
to ensure thego.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.
- [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.