|
1 | 1 | # Release Process |
2 | 2 |
|
3 | | -The Kubernetes Template Project is released on an as-needed basis. The process is as follows: |
| 3 | +## Overview |
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` and inserts the changelog and pushes the tag with `git push $VERSION` |
8 | | -1. The release issue is closed |
9 | | -1. An announcement email is sent to `[email protected]` with the subject `[ANNOUNCE] kubernetes-template-project $VERSION is released` |
| 5 | +The Network Policy API project is has the following two main release components: |
| 6 | +- Kubernetes Custom Resource Definitions (CRDs) |
| 7 | +- Corresponding Go bindings for the API (`sigs.k8s.io/network-policy-api` Go package) |
| 8 | + |
| 9 | +This repository is the home for both of the above components. |
| 10 | + |
| 11 | +## Versioning strategy |
| 12 | +The versioning strategy for this project is covered in detail in [the release |
| 13 | +documentation]. |
| 14 | + |
| 15 | +[the release documentation]: site-src/versioning.md |
| 16 | + |
| 17 | +Adapted with :blue_heart: from the [gateway api project release documentation](https://gateway-api.sigs.k8s.io/) |
| 18 | + |
| 19 | +## Releasing a new version |
| 20 | + |
| 21 | +### Writing a Changelog |
| 22 | + |
| 23 | +To simplify release notes generation, we recommend using the [Kubernetes release |
| 24 | +notes generator](https://github.com/kubernetes/release/blob/master/cmd/release-notes): |
| 25 | + |
| 26 | +``` |
| 27 | +go install k8s.io/release/cmd/release-notes@latest |
| 28 | +export GITHUB_TOKEN=your_token_here |
| 29 | +release-notes --start-sha EXAMPLE_COMMIT --end-sha EXAMPLE_COMMIT --branch main --repo network-policy-api --org kubernetes-sigs |
| 30 | +``` |
| 31 | + |
| 32 | +This output will likely need to be reorganized and cleaned up a bit, but it |
| 33 | +provides a good starting point. Once you're satisfied with the changelog, create |
| 34 | +a PR. This must go through the regular PR review process and get merged into the |
| 35 | +`main` branch. Approval of the PR indicates community consensus for a new |
| 36 | +release. |
| 37 | + |
| 38 | +### Release Steps |
| 39 | + |
| 40 | +The following steps must be done by one of the [network-policy API maintainers][network-policy-api-team]: |
| 41 | + |
| 42 | +For a **PATCH** release: |
| 43 | +- Create a new branch in your fork named something like `<githubuser>/release-x.x.x`. Use the new branch |
| 44 | + in the upcoming steps. |
| 45 | +- Use `git` to cherry-pick all relevant PRs into your branch. |
| 46 | +- Update `pkg/generator/main.go` with the new semver tag and any updates to the API review URL. |
| 47 | +- Run the following command `BASE_REF=vmajor.minor.patch make generate` which |
| 48 | + will update generated docs and webhook with the correct version info. (Note |
| 49 | + that you can't test with these YAMLs yet as they contain references to |
| 50 | + elements which wont exist until the tag is cut and image is promoted to |
| 51 | + production registry.) |
| 52 | +- Create a pull request of the `<githubuser>/release-x.x.x` branch into the `release-x.x` branch upstream |
| 53 | + (which should already exist since this is a patch release). Add a hold on this PR waiting for at least |
| 54 | + one maintainer/codeowner to provide a `lgtm`. |
| 55 | +- Verify the CI tests pass and merge the PR into `release-x.x`. |
| 56 | +- Create a tag using the `HEAD` of the `release-x.x` branch. This can be done using the `git` CLI or |
| 57 | + Github's [release][release] page. |
| 58 | +- Run the `make build-install-yaml` command which will generate install files in the `release/` directory. |
| 59 | + Attach these files to the Github release. |
| 60 | +- Update the `README.md` and `site-src/guides/index.md` files to point links and examples to the new release. |
| 61 | + |
| 62 | +For a **MAJOR** or **MINOR** release: |
| 63 | + |
| 64 | +- Cut a `release-major.minor` branch that we can tag things in as needed. |
| 65 | +- Check out the `release-major.minor` release branch locally. |
| 66 | +- Update `pkg/generator/main.go` with the new semver tag and any updates to the API review URL. |
| 67 | +- Run the following command `BASE_REF=vmajor.minor.patch make generate` which |
| 68 | + will update generated docs and webhook with the correct version info. (Note |
| 69 | + that you can't test with these YAMLs yet as they contain references to |
| 70 | + elements which wont exist until the tag is cut and image is promoted to |
| 71 | + production registry.) |
| 72 | +- Verify the CI tests pass before continuing. |
| 73 | +- Create a tag using the `HEAD` of the `release-x.x` branch. This can be done using the `git` CLI or |
| 74 | + Github's [release][release] page. |
| 75 | +- Run the `make build-install-yaml` command which will generate install files in the `release/` directory. |
| 76 | + Attach these files to the Github release. |
| 77 | +- Update the `README.md` and `site-src/guides/index.md` files to point links and examples to the new release. |
| 78 | + |
| 79 | +For an **RC** release: |
| 80 | + |
| 81 | +- Update `pkg/generator/main.go` with the new semver tag and any updates to the API review URL. |
| 82 | +- Run the following command `BASE_REF=vmajor.minor.patch make generate` which |
| 83 | + will update generated docs and webhook with the correct version info. (Note |
| 84 | + that you can't test with these YAMLs yet as they contain references to |
| 85 | + elements which wont exist until the tag is cut and image is promoted to |
| 86 | + production registry.) |
| 87 | +- Include the changelog update in this PR. |
| 88 | +- Merge the update PR. |
| 89 | +- Tag the release using the commit on `main` where the changelog update merged. |
| 90 | + This can be done using the `git` CLI or Github's [release][release] |
| 91 | + page. |
| 92 | +- Run the `make build-install-yaml` command which will generate |
| 93 | + install files in the `release/` directory. |
| 94 | +- Attach these files to the Github release. |
| 95 | + |
| 96 | +[release]: https://github.com/kubernetes-sigs/network-policy-api/releases |
| 97 | +[network-policy-api-team]: https://github.com/kubernetes/org/blob/main/config/kubernetes-sigs/sig-network/teams.yaml |
0 commit comments