Publishing a new kcp release
Note
You currently need write access to the kcp-dev/kcp repository to perform these tasks.
Create git tags
Prerequisite - make sure you have a GPG signing key
- 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
Create the tags
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
, changeREF
accordingly -
If you are creating a release from a release branch, change
main
inREF
accordingly, or you can makeREF
a commit hash. -
Tag the
sdk
module, following the same logic as above forREF
andTAG
Push the tags
If it's a new minor version
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 Generate release notes
Create a release branch
Set REMOTE
, REF
, and VERSION
as appropriate.
REMOTE=upstream
REF="$REMOTE/main"
VERSION=1.2
git checkout -b "release-$VERSION" "$REF"
git push "$REMOTE" "release-$VERSION"
Generate release notes
To generate release notes from the information in PR descriptions you should use Kubernetes' release-notes 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:
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).
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).
Review/edit/publish the release in GitHub
The goreleaser 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 releases 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.
Trigger documentation deployment
Documentation for the respective release branch needs to be triggered manually after the release branch has been pushed.
- Navigate to the Generate and push docs 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 docs.kcp.io.
Notify
- 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 #kcp-dev Slack channel