Mirroristas/etcd
2
0
Fork 0
mirror of https://github.com/etcd-io/etcd.git synced 2024-09-27 06:25:44 +00:00
Code Issues Packages Projects Releases Wiki Activity

Keep release process up to date.

Browse Source 
Signed-off-by: James Blair <mail@jamesblair.net>
This commit is contained in:
James Blair 2024-08-03 20:53:56 +12:00
parent e758ffc25a
commit 2221d46689
No known key found for this signature in database
1 changed files with 17 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
Documentation/contributor-guide/release.md
View File

@ -20,15 +20,15 @@ All release version numbers follow the format of [semantic versioning 2.0.0](htt
### 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.
- Ensure the latest upgrade documentation is available.
- Ensure the relevant [milestone](https://github.com/etcd-io/etcd/milestones) on GitHub is complete. All referenced issues should be closed or moved elsewhere.
- Ensure the latest [upgrade documentation](https://etcd.io/docs/next/upgrades) is available.
- Bump [hardcoded MinClusterVerion in the repository](https://github.com/etcd-io/etcd/blob/v3.4.15/version/version.go#L29), if necessary.
- Add feature capability maps for the new version, if necessary.
### Patch version release
- To request a backport, developers submit cherry-pick 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 cherrypick PRs should target the appropriate release branch (`base:release-<major>-<minor>`). The k8s infra cherry pick robot `/cherrypick <branch>` PR chatops command 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 its predecessor.
- The release patch manager will cherry-pick these commits starting from the oldest one into stable branch.
@ -66,28 +66,31 @@ which don't need to be executed before releasing each version.
### Release steps
1. Raise an issue to publish the release plan, e.g. [issues/17350](https://github.com/etcd-io/etcd/issues/17350).
2. Verify you can pass the authentication to the image registries,
2. Raise a `kubernetes/org` pull request to temporarily elevate permissions for the GitHub release team.
3. Once permissions are elevated, temporarily relax [branch protections](https://github.com/etcd-io/etcd/settings/branches) to allow pushing changes directly to `release-*` branches in GitHub.
4. Verify you can pass the authentication to the image registries,
- `docker login gcr.io`
- `docker login quay.io`
3. Clone the etcd repository and checkout the target branch,
5. Clone the etcd repository and checkout the target branch,
- `git clone git@github.com:etcd-io/etcd.git`
- `git checkout release-3.X`
4. Run the release script under the repository's root directory, replacing `${VERSION}` with a value without the `v` prefix, i.e. `3.5.13`.
6. Run the release script under the repository's root directory, replacing `${VERSION}` with a value without the `v` prefix, i.e. `3.5.13`.
- `DRY_RUN=false ./scripts/release.sh ${VERSION}`
It generates all release binaries under the directory `./release` and images. Binaries are pushed to the Google Cloud bucket
under project `etcd-development`, and images are pushed to `quay.io` and `gcr.io`.
5. Publish the release page on GitHub
7. Publish the release page on GitHub
- Set the release title as the version name
- Choose the correct release tag (generated from step #4)
- Follow the format of previous release pages
- Attach the generated binaries and signature file
- Select whether it's a pre-release
- Publish the release
6. Announce to the etcd-dev googlegroup
8. Announce to the etcd-dev googlegroup
Follow the format of previous release emails sent to etcd-dev@googlegroups.com, see an example below. After sending out the email, ask one of the mailing list maintainers to approve the email from the pending list.
```
```text
Hello,
etcd v3.4.30 is now public!
@ -98,9 +101,11 @@ Thanks to everyone who contributed to the release!
etcd team
```
7. Update the changelog to reflect the correct release date.
8. Paste the release link to the issue raised in Step 1 and close the issue.
9. Crease a new stable branch through `git push origin release-${VERSION_MAJOR}.${VERSION_MINOR}` if this is a new major or minor stable release.
9. Update the changelog to reflect the correct release date.
10. Paste the release link to the issue raised in Step 1 and close the issue.
11. Restore standard branch protection settings and raise a follow-up `kubernetes/org` pull request to return to least privilege permissions.
12. Crease a new stable branch through `git push origin release-${VERSION_MAJOR}.${VERSION_MINOR}` if this is a new major or minor stable release.
#### Release known issues