Project: KUDO (App Definition and Development / Application Definition & Image Build)
File: RELEASE.md

The `HEAD` of `main` branch is considered the most active development, to which new features and bug fixes are applied. The expectation is that main will always build and pass tests. Development is incremental. It is expected that pull-requests are either: complete and fully integrated into code execution path, or have a feature switch which must be enabled until code completion is reached. `HEAD` on main is expected to be in a state that it could be released. The next major release will be tagged and released from main. If the current released version is `v0.3.1` and the next major release is `v0.4.0`, then when it is deemed appropriate `v0.4.0` will be tagged off main, followed by a release. From that tag work will continue on main. If it is necessary in the future to have a patch release for `v0.4.1`, a branch will be created off the `v0.4.0` tag with the nomenclature of `releases/{major.minor}`, in this example `releases/0.4`. Branches matching `releases/*` are protected branches in the repository. The `HEAD` of the release branches follows the same conventions as main. It is expected that `HEAD` of the release branch is always in a releasable state. The purpose of the release branch is for bug fixes only. New features should not be targeted to a release branch. Pull request for documentation (in the repo) should be prepared and reviewed at the same time as the pull request for any user-visible (documentation-worthy) change. The description for the code change PR should link to the documentation PR (and vice-versa). The documentation PR should be made against the branch dedicated to next release, and merged as soon as its corresponding PR(s) against the `kudo` repo is/are merged. The name of the release-dedicated branch is `post-vx.y.z` where `x.y.z` is the previous release. This gives us the ability to have each branch be used for only a single release without knowing in advance what the exact version number will be up-front. Bug fixes are expected to be worked on and applied to `main`. If the fix is needed for a previously supported release version of KUDO, then a backport is expected. The bug fix pull request is expected to be marked with a `backport` label. If a bug fix has to be backported to a previous version, it is expected when possible that the backport is a `git cherry-pick`, updated if necessary to conform to previous code and

On occasion a cherry-pick is too much of a burden. In this case, fix the bug as a new pull request against the release branch. Provide the same title and details of the original pull request for traceability. The KUDO Project is aiming to do monthly minor releases but the period could be even shorter if necessary. The process is as follows: Every release should have an appointed release manager (RM) RM is responsible for following the process below RM should announce the release in the public at least two days prior to the date RM makes sure all PRs that need to go into the release are merged prior to the process starting RM prepares a pre-release at least 2 days before the release process is started and makes sure it's manually tested at least in the parts where we lack automatic tests for now (pre-release should be announced in the ) The official binaries for KUDO are created using . The defines the binaries which are supported for each release. Goreleaser is right now run manually from the RM computer. Ensure you have credential `GITHUB_TOKEN` set. The env must include `export GITHUB_TOKEN=<personal access token>`. provided from Github. The token must grant full access to: `repo`, `write:packages`, `read:packages`. Ensure you are logged into Docker hub and have rights to push to kudobuilder. Tag the kudo repo with expected release `git tag -a v0.2.0 -m "v0.2.0"` and push the tag `git push --tags`. Invoke goreleaser `goreleaser --rm-dist`. Update the GH release with release highlights and supported Kubernetes versions. There is a draft that contains categorized changes since the last release. It provides categories for highlights, breaking changes, and contributors which should be added the gorelease release notes. The changelog from the draft log is ignored. After the contents are copied, the draft can be deleted. Merge the of the repo dedicated to current release into `main`, following the regular GitHub pull request process. Immediately after that, create a `post-v0.2.0` branch for documentation for a future release from the tip of `main` of the repo, for example in the GitHub UI: Send an announcement email to with the subject `[ANNOUNCE] Kudo $VERSION is released` Run `./hack/generate_krew.sh` and submit the generated `kudo.yaml` to https://github.com/kubernetes-sigs/krew-index/. Update KUDO_VERSION of operators

Note: If there are issues with the release, any changes to the repository will result in it being considered "dirty" and not in a state to be released. It is possible outside of the standard release process to build a "snapshot" release using the following command: `goreleaser release --skip-publish --snapshot --rm-dist` This process will create a `dist` folder with all the build artifacts. The changelog is not created unless a full release is executed. If you are looking to get a "similar" changelog, install and execute `github-release-notes -org kudobuilder -repo kudo -since-latest-release`. Note: There is value in providing a blog of highlighted features after release against with a . Note: The release note for a full release should contain all changes since the last non-pre-release. For example a `0.16.0` changelog should contain all changes since `0.15.3`, not only the changes since `0.16.0-rc2`. As outlined above, when it is necessary to create a new release branch, it is necessary to update the to test merges against the correct branch. It is necessary replace all references to `main` with the appropriate release branch. When cutting a patch release, for example `v0.3.3`, it is necessary to ensure that all bugs fixed on main after `v0.3.2` have landed on the release branch, `releases/0.3` in this case. Cutting pre-release is very similar to cutting a stable release. That is because our `.goreleaser.yml` contains `prerelease: auto` which automatically detects a pre-release if the tag name looks like a pre-release. For pre-releases, we're not pushing docker images to the official repo. This is intentional because the following setting is set in `.goreleaser.yml` - `dockers.skip_push: auto`. That is because for pre-release, we don't want to update the latest tag just yet. Even though there is no push, goreleaser still builds the images for you. This is the full pre-release step by step: Ensure you have credential `GITHUBTOKEN` set. The env must include `export GITHUBTOKEN=<personal access token>`. provided from Github. The token must grant full access to: repo, write:packages, read:packages. Ensure you are logged into Docker hub and have rights to push to kudobuilder. Tag repo with expected pre-release (the name of the tag has to contain e.g. rc1 or similar) `git tag -a v0.2.0-rc1 -m "v0.2.0-rc1"` && push tag `git push --tags`. Invoke goreleaser `goreleaser --rm-dist`. Push only versioned docker image via `docker push kudobuilder/controller:v0.2.0-rc1` Note: The release notes for a pre-release should contain all changes since any previously released version. For example `0.16.0-rc1` should list all changes since `0.15.3` if that was the latest `0.15` release. `0.16.0-rc2` would contain all changes since `0.16.0-rc1`.