From 0842eb7016d3ad58e4d8d63839bae1bce1890ac3 Mon Sep 17 00:00:00 2001 From: Tobias Klauser Date: Thu, 15 Jul 2021 12:15:43 +0200 Subject: [PATCH] RELEASE.md: document release process Document the release process for Cilium CLI. Instructions are based on `RELEASE.md` in the Hubble repo. Note that in addition to the the releases so far, we also update `stable.txt` and publish the changelog in the release notes. Signed-off-by: Tobias Klauser --- RELEASE.md | 104 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 104 insertions(+) create mode 100644 RELEASE.md diff --git a/RELEASE.md b/RELEASE.md new file mode 100644 index 0000000000..643a634fd5 --- /dev/null +++ b/RELEASE.md @@ -0,0 +1,104 @@ +# RELEASE + +Release process and checklist for `cilium-cli`. + +## Prep the variables + +These variables will be used in the commands throughout the document to allow +copy-pasting. + +### Release hash + +Identify which commit will serve as the release point. + +All releases currently stem from the master branch. + + export RELEASE_HASH= + +### Version + +If releasing a new version 5.4.0 with the latest release being 5.3.8, for +example, they will look as follows: + + export MAJOR=5 + export MINOR=4 + export PATCH=0 + export LAST_RELEASE=5.3.8 + +## Create release prep branch + +This branch will be used to prepare all the necessary things to get ready for +release. + + git checkout -b v$MAJOR.$MINOR.$PATCH-prep + +## Prepare the release notes + +Using https://github.com/cilium/release, prepare the release notes between the +last minor version (latest patch) and current. + + ./release --repo cilium/cilium-cli --base v$LAST_RELEASE --head master + **Other Changes:** + * install: Add a hidden --base-version flag (#418, @michi-covalent) + * Makefile: introduce GO_BUILD variable (#432, @tklauser) + * Prepare for release v0.8.5 (#428, @michi-covalent) + * Run "Post-test information gathering" step on cancellation (#426, @michi-covalent) + * skip Succeeded pods (#431, @xyz-li) + ... etc ... + +## Update files for the new release + +Update the version in `VERSION` and `stable.txt`, then commit the changes to +the prep branch: + + echo v$MAJOR.$MINOR.$PATCH > VERSION + echo v$MAJOR.$MINOR.$PATCH > stable.txt + git add VERSION stable.txt + git commit -s -m "Prepare for release v$MAJOR.$MINOR.$PATCH" + +Consider that the Cilium repository uses the version specified in `stable.txt` +in the master branch for its CI workflows. In certain cases (e.g. for breaking +changes which require changes in the Cilium repo first), the version in +`stable.txt` might need to be updated in a separate PR. + +## Update the `VERSION` file for next development cycle + +Usually this only consists of bumping the patch version and adding the `-dev` +suffix, e.g. + + NEXT_PATH=$((PATCH+1)) + echo v$MAJOR.$MINOR.$NEXT_PATH-dev > VERSION + +Then commit the changes to the prep branch: + + git add VERSION + git commit -s -m "Prepare for v$MAJOR.$MINOR.<$PATCH+1> development" + +## Push the prep branch and open a Pull Request + +The pull request has to be `v$MAJOR.$MINOR.$PATCH-prep -> master` + +Once the pull request is approved and merged, a tag can be created. + +## Tag a release + +Identify the right commit and tag the release. Usually, the commit modifying +the version in the VERSION file is tagged. + +Example: + + git tag -a v0.8.5 -m 'v0.8.5' + +Then push the tag. + +Example: + + git push origin v0.8.5 + +## Update the GitHub release notes + +When a tag is pushed, a GitHub Action job takes care of creating a new GitHub +draft release, building artifacts and attaching them to the draft release. + +The release notes need to be manually added before manually publishing the +release.