Project: kcp (Orchestration & Management / Scheduling & Orchestration)
File: publishing-a-new-kcp-release.md

description: > Information on the kcp release process. !!! note You currently need write access to the repository to perform these tasks. <https://docs.github.com/en/authentication/managing-commit-signature-verification/generating-a-new-gpg-key> <https://docs.github.com/en/authentication/managing-commit-signature-verification/adding-a-gpg-key-to-your-github-account> <https://docs.github.com/en/authentication/managing-commit-signature-verification/telling-git-about-your-signing-key> kcp has 2 go modules, and a unique tag is needed for each module every time we create a new release. `git fetch` from the main kcp repository (kcp-dev/kcp) to ensure you have the latest commits Tag the main module If your git remote for kcp-dev/kcp is named something other than `upstream`, change `REF` accordingly If you are creating a release from a release branch, change `main` in `REF` accordingly, or you can make `REF` a commit hash. ```shell REF=upstream/main TAG=v1.2.3 git tag --sign --message "$TAG" "$TAG" "$REF" ``` Tag the `sdk` module, following the same logic as above for `REF` and `TAG` ```shell REF=upstream/main TAG=v1.2.3 git tag --sign --message "sdk/$TAG" "sdk/$TAG" "$REF" ``` Tag the `cli` module, following the same logic as above for `REF` and `TAG` ```shell REF=upstream/main TAG=v1.2.3 git tag --sign --message "cli/$TAG" "cli/$TAG" "$REF" ``` ```shell REMOTE=upstream TAG=v1.2.3 git push "$REMOTE" "$TAG" "sdk/$TAG" "cli/$TAG" ``` If this is the first release of a new minor version (e.g. the last release was v0.7.x, and you are releasing the first 0.8.x version), follow the following steps. Otherwise, you can skip to Set `REMOTE`, `REF`, and `VERSION` as appropriate. ```shell REMOTE=upstream REF="$REMOTE/main" VERSION=1.2 git checkout -b "release-$VERSION" "$REF" git push "$REMOTE" "release-$VERSION" ``` To generate release notes from the information in PR descriptions you should use Kubernetes' tool. This tool will use the `release-notes` blocks in PR descriptions and the `kind/` labels on those PRs to find user-facing changes and categorize them. You can run the command below to install the latest version of it: ```shell go install k8s.io/release/cmd/release-notes@latest ``` To use `release-notes` you will need to generate a GitHub API token (Settings -> Developers settings -> Personal access tokens -> Fine-grained tokens). A token with Public Repositories (read-only) repository access and no further permissions is sufficient. Store the token somewhere safe and export it as `GITHUB_TOKEN` environment variable. Then, run run the `release-notes` tool (set `PREV_VERSION` to the version released before the one you have just released). ```shell TAG=v1.2.3 PREV_TAG=v1.2.2 release-notes \ --required-author='' \ --org kcp-dev \ --repo kcp \ --branch main \ --start-rev $PREV_TAG \ --end-rev $TAG \ --output CHANGELOG.md ``` Don't commit the `CHANGELOG.md` to the repository, just keep it around to update the release on GitHub (next step). The workflow automatically creates a draft GitHub release for each tag. Navigate to the draft release for the tag you just pushed. You'll be able to find it under the page. If the release notes have been pre-populated, delete them. Copy release notes from the `CHANGELOG.md` file you generated in the previous step. Publish the release. Documentation for the respective release branch needs to be triggered manually after the release branch has been pushed. Navigate to the GitHub Action. Hit the "Run forkflow" button, run workflow against `release-$VERSION`. Make sure the triggered workflow ran and deployed a new version of the documentation to . Create an email addressed to kcp-dev@googlegroups.com and kcp-users@googlegroups.com Subject: `[release] <version>` e.g. `[release] v0.8.0` In the body, include noteworthy changes Provide a link to the release in GitHub for the full release notes Post a message in the Slack channel