Skip to content

Latest commit

 

History

History
78 lines (51 loc) · 5.43 KB

RELEASE.md

File metadata and controls

78 lines (51 loc) · 5.43 KB
Raw

Development and Release Process

Development Processes

Main

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.

Documentation

Documentation is now stored in the main repository, and should be updated in the same PRs which change functionality.

Bug Fixes

Bug fixes are expected to be worked on and applied to main.

If the fix is needed for a previously supported release version of KUTTL, 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 architecture.

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.

Release Request Process

The KUTTL Project is aiming to do monthly minor releases but the period could be even shorter if necessary. The process is as follows:

  1. Every release should have an appointed release manager (RM)
  2. RM is responsible for following the process below
  3. RM should announce the release in the public #kudo slack channel at least two days prior to the date
  4. RM makes sure all PRs that need to go into the release are:
    1. labeled with the release/* labels as appropriate (the release drafter GitHub Action depends on these)
    2. merged prior to the process starting

Release Process

The official binaries for KUTTL are created using goreleaser. The .goreleaser.yml defines the binaries which are supported for each release. Goreleaser is right now run manually from the RM computer. The following are preconditions for the release process:

  1. Ensure you have credential GITHUB_TOKEN set. The env must include export GITHUB_TOKEN=<personal access token>. Help provided from Github. The token must grant access to: repo, write:packages, read:packages.

The release process is:

  1. Tag the kuttl repo with expected release git tag -a v0.2.0 -m "v0.2.0" and push the tag git push --tags.
  2. Invoke goreleaser goreleaser --clean.
  3. Update the GH release with release highlights. There is a draft release prepared by release drafter GitHub Action, 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 or left as is.
  4. Send an announcement email to [email protected] with the subject [ANNOUNCE] KUTTL $VERSION is released
  5. Send an announcement message to Kubernetes Slack channel #kudo.
  6. Run ./hack/generate_krew.sh and submit the generated kuttl.yaml to https://github.com/kubernetes-sigs/krew-index/.

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 github-release-notes and execute github-release-notes -org kudobuilder -repo kuttl -since-latest-release.

Docker Release

The docker release is accomplished by make docker-release. Details on what is required are provided in Docker.md.

Cutting a Patch Release

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.