Skip to content

Latest commit

 

History

History
69 lines (41 loc) · 2.44 KB

RELEASE.md

File metadata and controls

69 lines (41 loc) · 2.44 KB
Raw

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 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 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 [email protected] with the subject [ANNOUNCE] kubernetes-template-project $VERSION is released