|
2 | 2 |
|
3 | 3 | The Kubernetes C Client Project is released on an as-needed basis. The process is as follows:
|
4 | 4 |
|
5 |
| -1. An issue is proposing a new release with a changelog since the last release |
6 |
| -1. All [OWNERS](OWNERS) must LGTM this release |
7 |
| -1. 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` |
| 5 | +## Request |
| 6 | + |
| 7 | +An issue is proposing a new release with a changelog since the last release |
| 8 | + |
| 9 | +All [OWNERS](OWNERS) must LGTM this release |
| 10 | + |
| 11 | +## Prepare |
| 12 | + |
| 13 | +Before release, we need to determine our release branch. |
| 14 | + |
| 15 | +The release branch will always be of the form `release-<MAJOR>.<MINOR>`. Any |
| 16 | +time a `<MAJOR>` or `<MINOR>` version number is incremented, a new release |
| 17 | +branch needs to be created with `git checkout -b release-<MAJOR>.<MINOR>` _from |
| 18 | +the branch containing the changes you want to release_. If you are only |
| 19 | +releasing bug fixes for an existing `<MAJOR>.<MINOR>` release (a patch |
| 20 | +release), you simply checkout that existing release branch `git checkout |
| 21 | +release-<MAJOR>.<MINOR>`. |
| 22 | + |
| 23 | +Now we are ready to perform the release. |
| 24 | + |
| 25 | +## Release |
| 26 | + |
| 27 | +There are 2 options to release: via GitHub Action or by manul |
| 28 | + |
| 29 | +### Release via GitHub Action |
| 30 | + |
| 31 | +Maintainers meeting the following requirements will be able to perform automated |
| 32 | +release: |
| 33 | + |
| 34 | +* Has "collaborator" permission or higher (otherwise they can't run the job manually). |
| 35 | +* Should be in the OWNERS file. |
| 36 | + |
| 37 | +#### Fill in the release workflow inputs manually |
| 38 | + |
| 39 | +The GitHub Action workflow [Release](https://github.com/kubernetes-client/c/actions/workflows/release.yml) will require three manual inputs: |
| 40 | + |
| 41 | +* The branch on which the workflow runs, must be a release branch, e.g. `release-X.Y` |
| 42 | + |
| 43 | +* The releasing version, must be a valid semver `X.Y.Z` (without "v" prefix). |
| 44 | + |
| 45 | +* Dry-Run: Indicating whether the release job will push the generated tag to the release branch and actually do a GitHub release. |
| 46 | + |
| 47 | +Fill in the inputs, then click "Run" to start the job. |
| 48 | + |
| 49 | +#### Release note, announcements |
| 50 | + |
| 51 | +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. |
| 52 | + |
| 53 | +In the end, manually update the release notes and publish the release on the GitHub release page. |
| 54 | + |
| 55 | +### Release by manual |
| 56 | + |
| 57 | +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` |
8 | 58 |
|
9 | 59 | e.g
|
10 | 60 | ```shell
|
11 | 61 | git tag -a v0.1.0 -m "version 0.1.0"
|
12 | 62 | git push origin v0.1.0
|
13 | 63 | ```
|
14 | 64 |
|
15 |
| -1. The release issue is closed |
16 |
| -1. An announcement email is sent to `[email protected]` with the subject `[ANNOUNCE] kubernetes-template-project $VERSION is released` |
| 65 | +## Announcement |
| 66 | + |
| 67 | +The release issue is closed |
| 68 | + |
| 69 | +An announcement email is sent to `[email protected]` with the subject `[ANNOUNCE] kubernetes-template-project $VERSION is released` |
0 commit comments