|
2 | 2 |
|
3 | 3 | The Kubebuilder 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. You will need to use the [kubebuilder-release-tools][kubebuilder-release-tools] to generate the notes. See [here][release-notes-generation] |
6 |
| -1. All [OWNERS](OWNERS) must LGTM this release |
7 |
| -1. An OWNER runs `git tag -s $VERSION` and pushes the tag with `git push $VERSION`. Note that after the OWNER push the tag the CI will automatically add the release notes and the assets. |
8 |
| -1. A PR needs to be created to merge `master` branch into `book-v3` to pick up the new docs. |
9 |
| -1. The release issue is closed |
10 |
| -1. An announcement email is sent to `[email protected]` with the subject `[ANNOUNCE] kubebuilder $VERSION is released` |
| 5 | +**Note:** Releases are done from the `release-MAJOR.MINOR` branches. For PATCH releases it is not required |
| 6 | +to create a new branch. Instead, you will just need to ensure that all major fixes are cherry-picked into the respective |
| 7 | +`release-MAJOR.MINOR` branch. To know more about versioning check https://semver.org/. |
11 | 8 |
|
12 |
| -**Notes:** This process does not apply to EAP or alpha (pre-)releases which may be cut at any time for development |
13 |
| -and testing. |
| 9 | +**Note:** Before `3.5.*` release this project was released based on `MAJOR`. A change to the |
| 10 | +the process was done to ensure that we have an aligned process under the org (similar to `controller-runtime` and |
| 11 | +`controller-tools`) and to make it easier to produce patch releases. |
14 | 12 |
|
15 |
| -For further information about versioning and update the Kubebuilder binaries check the [versioning][release-process] doc. |
| 13 | +## How to do a release |
| 14 | + |
| 15 | +### Create the new branch and the release tag |
| 16 | + |
| 17 | +1. Create a new branch `git checkout -b release-<MAJOR.MINOR>` from master |
| 18 | +2. Push the new branch to the remote repository |
| 19 | + |
| 20 | +### Now, let's generate the changelog |
| 21 | + |
| 22 | +1. Create the changelog from the new branch `release-<MAJOR.MINOR>` (`git checkout release-<MAJOR.MINOR>`). |
| 23 | + You will need to use the [kubebuilder-release-tools][kubebuilder-release-tools] to generate release notes. See [here][release-notes-generation] |
| 24 | + |
| 25 | +> **Note** |
| 26 | +> - You will need to have checkout locally from the remote repository the previous branch |
| 27 | +> - Also, ensure that you fetch all tags from the remote `git fetch --all --tags` |
| 28 | +
|
| 29 | +### Draft a new release from GitHub |
| 30 | + |
| 31 | +1. Create a new tag with the correct version from the new `release-<MAJOR.MINOR>` branch |
| 32 | +2. Add the changelog on it and publish. Now, the code source is released ! |
| 33 | + |
| 34 | +### Announce the new release: |
| 35 | + |
| 36 | +1. Publish the new release on the Slack channel, i.e: |
| 37 | + |
| 38 | +```` |
| 39 | +:announce: Kubebuilder v3.5.0 has been released! |
| 40 | +This release includes a Kubernetes dependency bump to v1.24. |
| 41 | +For more info, see the release page: https://github.com/kubernetes-sigs/kubebuilder/releases/tag/v3.5.0 |
| 42 | + :tada: Thanks to all our contributors! |
| 43 | +```` |
| 44 | + |
| 45 | +2. An announcement email is sent to `[email protected]` with the subject `[ANNOUNCE] Kubebuilder $VERSION is released` |
16 | 46 |
|
17 | 47 | ## HEAD releases
|
18 | 48 |
|
|
0 commit comments