Version 3.3.13 home Download and build Libraries and tools Metrics Branch management Demo Discovery service protocol etcd release guide Frequently Asked Questions (FAQ) Logging conventions Production users Reporting bugs Tuning Benchmarks Benchmarking etcd v2.1.0 Benchmarking etcd v2.2.0 Benchmarking etcd v2.2.0-rc Benchmarking etcd v2.2.0-rc-memory Benchmarking etcd v3 Storage Memory Usage Benchmark Watch Memory Usage Benchmark Developer guide etcd API Reference etcd concurrency API Reference Experimental APIs and features gRPC naming and discovery Interacting with etcd Set up a local cluster System limits Why gRPC gateway etcd v3 API Learning etcd client architecture Client feature matrix Data model etcd v3 authentication design etcd versus other key-value stores etcd3 API Glossary KV API guarantees Learner Operations guide Clustering Guide Configuration flags Design of runtime reconfiguration Disaster recovery etcd gateway Failure modes gRPC proxy Hardware recommendations Maintenance Migrate applications from using API v2 to API v3 Monitoring etcd Performance Role-based access control Run etcd clusters inside containers Runtime reconfiguration Supported systems Transport security model Versioning Platforms Amazon Web Services Container Linux with systemd FreeBSD Upgrading Upgrade etcd from 2.3 to 3.0 Upgrade etcd from 3.0 to 3.1 Upgrade etcd from 3.1 to 3.2 Upgrade etcd from 3.2 to 3.3 Upgrade etcd from 3.3 to 3.4 Upgrade etcd from 3.4 to 3.5 Upgrading etcd clusters and applications

etcd release guide

The guide talks about how to release a new version of etcd.

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

Release management

etcd community members are assigned to manage the release each etcd major/minor version as well as manage patches and to each stable release branch. The managers are responsible for communicating the timelines and status of each release and for ensuring the stability of the release branch.

ReleasesManager
3.1 patch (post 3.1.0)Joe Betz @jpbetz
3.2 patch (post 3.2.0)Joe Betz @jpbetz
3.3 patch (post 3.3.0)Gyuho Lee @gyuho

Prepare release

Set desired version as environment variable for following steps. Here is an example to release 2.3.0:

export VERSION=v2.3.0
export PREV_VERSION=v2.2.5

All releases version numbers follow the format of semantic versioning 2.0.0.

Major, minor version release, or its pre-release

  • 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.
  • Bump hardcoded MinClusterVerion in the repository, if necessary.
  • Add feature capability maps for the new version, if necessary.

Patch version release

  • To request a backport, devlopers submit cherrypick PRs targeting the release branch. The commits should not include merge commits. The commits should be restricted to bug fixes and security patches.
  • The cherrypick PRs should target the appropriate release branch (base:release-<major>-<minor>). hack/patch/cherrypick.sh may be used to automatically generate cherrypick PRs.
  • The release patch manager reviews the cherrypick PRs. Please discuss carefully what is backported to the patch release. Each patch release should be strictly better than it’s predecessor.
  • The release patch manager will 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.
  • Put [GH XXXX] 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.
  • Find PRs with release-note label and explain them in NEWS file, as a straightforward summary of changes for end-users.

Tag version

  • Bump hardcoded Version in the repository 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 git show tags/$VERSION.
  • Push the tag to GitHub through git push origin tags/$VERSION. This assumes origin corresponds to “https://github.com/etcd-io/etcd".

Build release binaries and images

  • Ensure acbuild is available.
  • Ensure docker is available.

Run release script in root directory:

TAG=gcr.io/etcd-development/etcd ./scripts/release.sh ${VERSION}

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

Sign binaries, images, and source code

etcd project key must be used to sign the generated binaries and images.$SUBKEYID is the key ID of etcd project Yubikey. Connect the key and run gpg2 --card-status to get the ID.

The following commands are used for public release sign:

cd release
for i in etcd-*{.zip,.tar.gz}; do gpg2 --default-key $SUBKEYID --armor --output ${i}.asc --detach-sign ${i}; done
for i in etcd-*{.zip,.tar.gz}; do gpg2 --verify ${i}.asc ${i}; done

# sign zipped source code files
wget https://github.com/etcd-io/etcd/archive/${VERSION}.zip
gpg2 --armor --default-key $SUBKEYID --output ${VERSION}.zip.asc --detach-sign ${VERSION}.zip
gpg2 --verify ${VERSION}.zip.asc ${VERSION}.zip

wget https://github.com/etcd-io/etcd/archive/${VERSION}.tar.gz
gpg2 --armor --default-key $SUBKEYID --output ${VERSION}.tar.gz.asc --detach-sign ${VERSION}.tar.gz
gpg2 --verify ${VERSION}.tar.gz.asc ${VERSION}.tar.gz

The public key for GPG signing can be found at CoreOS Application Signing Key

Publish release page in GitHub

  • Set release title as the version name.
  • Follow the format of previous release pages.
  • Attach the generated binaries and signatures.
  • Select whether it is a pre-release.
  • Publish the release!

Publish docker image in gcr.io

  • Push docker image:
gcloud docker -- login -u _json_key -p "$(cat /etc/gcp-key-etcd.json)" https://gcr.io

for TARGET_ARCH in "-arm64" "-ppc64le" ""; do
  gcloud docker -- push gcr.io/etcd-development/etcd:${VERSION}${TARGET_ARCH}
done
  • Add latest tag to the new image on gcr.io if this is a stable release.

Publish docker image in Quay.io

  • Build docker images with quay.io:
for TARGET_ARCH in "amd64" "arm64" "ppc64le"; do
  TAG=quay.io/coreos/etcd GOARCH=${TARGET_ARCH} \
    BINARYDIR=release/etcd-${VERSION}-linux-${TARGET_ARCH} \
    BUILDDIR=release \
    ./scripts/build-docker ${VERSION}
done
  • Push docker image:
docker login quay.io

for TARGET_ARCH in "-arm64" "-ppc64le" ""; do
  docker push quay.io/coreos/etcd:${VERSION}${TARGET_ARCH}
done
  • Add latest tag to the new image on quay.io if this is a stable release.

Announce to the etcd-dev Googlegroup

  • Follow the format of previous release emails.
  • Make sure to include a list of authors that contributed since the previous release - something like the following might be handy:
git log ...${PREV_VERSION} --pretty=format:"%an" | sort | uniq | tr '\n' ',' | sed -e 's#,#, #g' -e 's#, $##'

Post release

© etcd Authors 2020 | Documentation Distributed under CC-BY-4.0

© 2020 The Linux Foundation. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks.
For a list of trademarks of The Linux Foundation, please see our Trademark Usage page.

etcd release guide