70 lines
2.4 KiB
Markdown
70 lines
2.4 KiB
Markdown
# Release Process
|
|
|
|
The Kubernetes C Client Project is released on an as-needed basis. The process is as follows:
|
|
|
|
## Request
|
|
|
|
An issue is proposing a new release with a changelog since the last release
|
|
|
|
All [OWNERS](OWNERS) must LGTM this release
|
|
|
|
## Prepare
|
|
|
|
Before release, we need to determine our release branch.
|
|
|
|
The release branch will always be of the form `release-<MAJOR>.<MINOR>`. Any
|
|
time a `<MAJOR>` or `<MINOR>` version number is incremented, a new release
|
|
branch needs to be created with `git checkout -b release-<MAJOR>.<MINOR>` _from
|
|
the branch containing the changes you want to release_. If you are only
|
|
releasing bug fixes for an existing `<MAJOR>.<MINOR>` release (a patch
|
|
release), you simply checkout that existing release branch `git checkout
|
|
release-<MAJOR>.<MINOR>`.
|
|
|
|
Now we are ready to perform the release.
|
|
|
|
## Release
|
|
|
|
There are 2 options to release: via GitHub Action or by manul
|
|
|
|
### Release via GitHub Action
|
|
|
|
Maintainers meeting the following requirements will be able to perform automated
|
|
release:
|
|
|
|
* Has "collaborator" permission or higher (otherwise they can't run the job manually).
|
|
* Should be in the OWNERS file.
|
|
|
|
#### Fill in the release workflow inputs manually
|
|
|
|
The GitHub Action workflow [Release](https://github.com/kubernetes-client/c/actions/workflows/release.yml) will require three manual inputs:
|
|
|
|
* The branch on which the workflow runs, must be a release branch, e.g. `release-X.Y`
|
|
|
|
* The releasing version, must be a valid semver `X.Y.Z` (without "v" prefix).
|
|
|
|
* Dry-Run: Indicating whether the release job will push the generated tag to the release branch and actually do a GitHub release.
|
|
|
|
Fill in the inputs, then click "Run" to start the job.
|
|
|
|
#### Release note, announcements
|
|
|
|
After the release job successfully finishes, we're supposed to see a git tag `vX.Y.Z` pushed to the release branch, a GitHub draft release will also be packed on the tag.
|
|
|
|
In the end, manually update the release notes and publish the release on the GitHub release page.
|
|
|
|
### Release by manual
|
|
|
|
An OWNER runs `git tag -s $VERSION` or `git tag -a $VERSION` (If GPG-signed tag is not required) and inserts the changelog and pushes the tag with `git push origin $VERSION`
|
|
|
|
e.g
|
|
```shell
|
|
git tag -a v0.1.0 -m "version 0.1.0"
|
|
git push origin v0.1.0
|
|
```
|
|
|
|
## Announcement
|
|
|
|
The release issue is closed
|
|
|
|
An announcement email is sent to `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] kubernetes-template-project $VERSION is released`
|