The procedure includes some manual steps for sanity checking but it can probably be further scripted. Please keep this document up-to-date if you want to make changes to the release process.

All releases version numbers follow the format of .

  • Ensure the relevant milestone on GitHub is complete. All referenced issues should be closed, or moved elsewhere.
  • Remove this release from roadmap, if necessary.
  • Ensure the latest upgrade documentation is available.
  • Add feature capability maps for the new version, if necessary.

Patch Version Release

  • Discuss about commits that are backported to the patch release. The commits should not include merge commits.
  • Cherry-pick these commits starting from the oldest one into stable branch.

Write Release Note

  • Write introduction for the new release. For example, what major bug we fix, what new features we introduce or what performance improvement we make.
  • Write changelog for the last release. ChangeLog should be straightforward and easy to understand for the end-user.
  • Put at the head of change line to reference Pull Request that introduces the change. Moreover, add a link on it to jump to the Pull Request.

Tag Version

  • Bump to the latest version ${VERSION}.
  • Ensure all tests on CI system are passed.
  • Manually check etcd is buildable in Linux, Darwin and Windows.
  • Manually check upgrade etcd cluster of previous minor version works well.
  • Manually check new features work well.
  • Add a signed tag through git tag -s ${VERSION}.
  • Sanity check tag correctness through .
  • Ensure is available.

It generates all release binaries and images under directory ./release.

Sign Binaries and Images

The following commands are used for public release sign:

Publish Release Page in GitHub

  • Set release title as the version name.
  • Follow the format of previous release pages.
  • Attach the generated binaries, aci image and signatures.
  • Select whether it is a pre-release.
  • Publish the release!
  • Push docker image:
  • Add latest tag to the new image on quay.io if this is a stable release.

Announce to etcd-dev Googlegroup

  • Follow the format of .
  • Make sure to include a list of authors that contributed since the previous release - something like the following might be handy:

Post Release

  • Create new stable branch through git push origin ${VERSION_MAJOR}.${VERSION_MINOR} if this is a major stable release. This assumes corresponds to “.
  • Bump hardcoded Version in the repository to the version ${VERSION}+git.