go.etcd.io/etcd@v3.3.27+incompatible/Documentation/dev-internal/release.md (about) 1 --- 2 title: etcd release guide 3 --- 4 5 The guide talks about how to release a new version of etcd. 6 7 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. 8 9 ## Release management 10 11 etcd community members are assigned to manage the release each etcd major/minor version as well as manage patches 12 and to each stable release branch. The managers are responsible for communicating the timelines and status of each 13 release and for ensuring the stability of the release branch. 14 15 | Releases | Manager | 16 | -------- | ------- | 17 | 3.1 patch (post 3.1.0) | Joe Betz [@jpbetz](https://github.com/jpbetz) | 18 | 3.2 patch (post 3.2.0) | Joe Betz [@jpbetz](https://github.com/jpbetz) | 19 | 3.3 patch (post 3.3.0) | Gyuho Lee [@gyuho](https://github.com/gyuho) | 20 21 ## Prepare release 22 23 Set desired version as environment variable for following steps. Here is an example to release 2.3.0: 24 25 ``` 26 export VERSION=v2.3.0 27 export PREV_VERSION=v2.2.5 28 ``` 29 30 All releases version numbers follow the format of [semantic versioning 2.0.0](http://semver.org/). 31 32 ### Major, minor version release, or its pre-release 33 34 - Ensure the relevant milestone on GitHub is complete. All referenced issues should be closed, or moved elsewhere. 35 - Remove this release from [roadmap](https://github.com/etcd-io/etcd/blob/master/ROADMAP.md), if necessary. 36 - Ensure the latest upgrade documentation is available. 37 - Bump [hardcoded MinClusterVerion in the repository](https://github.com/etcd-io/etcd/blob/master/version/version.go#L29), if necessary. 38 - Add feature capability maps for the new version, if necessary. 39 40 ### Patch version release 41 42 - 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. 43 - 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. 44 - 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. 45 - The release patch manager will cherry-pick these commits starting from the oldest one into stable branch. 46 47 ## Write release note 48 49 - Write introduction for the new release. For example, what major bug we fix, what new features we introduce or what performance improvement we make. 50 - 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. 51 - Find PRs with `release-note` label and explain them in `NEWS` file, as a straightforward summary of changes for end-users. 52 53 ## Tag version 54 55 - Bump [hardcoded Version in the repository](https://github.com/etcd-io/etcd/blob/master/version/version.go#L30) to the latest version `${VERSION}`. 56 - Ensure all tests on CI system are passed. 57 - Manually check etcd is buildable in Linux, Darwin and Windows. 58 - Manually check upgrade etcd cluster of previous minor version works well. 59 - Manually check new features work well. 60 - Add a signed tag through `git tag -s ${VERSION}`. 61 - Sanity check tag correctness through `git show tags/$VERSION`. 62 - Push the tag to GitHub through `git push origin tags/$VERSION`. This assumes `origin` corresponds to "https://github.com/etcd-io/etcd". 63 64 ## Build release binaries and images 65 66 - Ensure `acbuild` is available. 67 - Ensure `docker` is available. 68 69 Run release script in root directory: 70 71 ``` 72 TAG=gcr.io/etcd-development/etcd ./scripts/release.sh ${VERSION} 73 ``` 74 75 It generates all release binaries and images under directory ./release. 76 77 ## Sign binaries, images, and source code 78 79 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. 80 81 The following commands are used for public release sign: 82 83 ``` 84 cd release 85 for i in etcd-*{.zip,.tar.gz}; do gpg2 --default-key $SUBKEYID --armor --output ${i}.asc --detach-sign ${i}; done 86 for i in etcd-*{.zip,.tar.gz}; do gpg2 --verify ${i}.asc ${i}; done 87 88 # sign zipped source code files 89 wget https://github.com/etcd-io/etcd/archive/${VERSION}.zip 90 gpg2 --armor --default-key $SUBKEYID --output ${VERSION}.zip.asc --detach-sign ${VERSION}.zip 91 gpg2 --verify ${VERSION}.zip.asc ${VERSION}.zip 92 93 wget https://github.com/etcd-io/etcd/archive/${VERSION}.tar.gz 94 gpg2 --armor --default-key $SUBKEYID --output ${VERSION}.tar.gz.asc --detach-sign ${VERSION}.tar.gz 95 gpg2 --verify ${VERSION}.tar.gz.asc ${VERSION}.tar.gz 96 ``` 97 98 The public key for GPG signing can be found at [CoreOS Application Signing Key](https://coreos.com/security/app-signing-key) 99 100 101 ## Publish release page in GitHub 102 103 - Set release title as the version name. 104 - Follow the format of previous release pages. 105 - Attach the generated binaries and signatures. 106 - Select whether it is a pre-release. 107 - Publish the release! 108 109 ## Publish docker image in gcr.io 110 111 - Push docker image: 112 113 ``` 114 gcloud docker -- login -u _json_key -p "$(cat /etc/gcp-key-etcd.json)" https://gcr.io 115 116 for TARGET_ARCH in "-arm64" "-ppc64le" ""; do 117 gcloud docker -- push gcr.io/etcd-development/etcd:${VERSION}${TARGET_ARCH} 118 done 119 ``` 120 121 - Add `latest` tag to the new image on [gcr.io](https://console.cloud.google.com/gcr/images/etcd-development/GLOBAL/etcd?project=etcd-development&authuser=1) if this is a stable release. 122 123 ## Publish docker image in Quay.io 124 125 - Build docker images with quay.io: 126 127 ``` 128 for TARGET_ARCH in "amd64" "arm64" "ppc64le"; do 129 TAG=quay.io/coreos/etcd GOARCH=${TARGET_ARCH} \ 130 BINARYDIR=release/etcd-${VERSION}-linux-${TARGET_ARCH} \ 131 BUILDDIR=release \ 132 ./scripts/build-docker ${VERSION} 133 done 134 ``` 135 136 - Push docker image: 137 138 ``` 139 docker login quay.io 140 141 for TARGET_ARCH in "-arm64" "-ppc64le" ""; do 142 docker push quay.io/coreos/etcd:${VERSION}${TARGET_ARCH} 143 done 144 ``` 145 146 - Add `latest` tag to the new image on [quay.io](https://quay.io/repository/coreos/etcd?tag=latest&tab=tags) if this is a stable release. 147 148 ## Announce to the etcd-dev Googlegroup 149 150 - Follow the format of [previous release emails](https://groups.google.com/forum/#!forum/etcd-dev). 151 - Make sure to include a list of authors that contributed since the previous release - something like the following might be handy: 152 153 ``` 154 git log ...${PREV_VERSION} --pretty=format:"%an" | sort | uniq | tr '\n' ',' | sed -e 's#,#, #g' -e 's#, $##' 155 ``` 156 157 - Send email to etcd-dev@googlegroups.com 158 159 ## Post release 160 161 - Create new stable branch through `git push origin ${VERSION_MAJOR}.${VERSION_MINOR}` if this is a major stable release. This assumes `origin` corresponds to "https://github.com/etcd-io/etcd". 162 - Bump [hardcoded Version in the repository](https://github.com/etcd-io/etcd/blob/master/version/version.go#L30) to the version `${VERSION}+git`.