6e03a95730
Add how Kata is doing the rolling release. Signed-off-by: Zvonko Kaiser <zkaiser@nvidia.com>
5.1 KiB
How to do a Kata Containers Release
This document lists the tasks required to create a Kata Release.
Requirements
- GitHub permissions to run workflows.
Versioning
The Kata Containers project uses semantic versioning for all releases. Semantic versions are comprised of three fields in the form:
MAJOR.MINOR.PATCH
When MINOR increases, the new release adds new features but without changing the existing behavior.
When MAJOR increases, the new release adds new features, bug fixes, or
both and which changes the behavior from the previous release (incompatible with previous releases).
A major release will also likely require a change of the container manager version used, -for example Containerd or CRI-O. Please refer to the release notes for further details.
Kata Containers follows a rolling release model with monthly snapshots.
New features, bug fixes, and improvements are continuously integrated into
main. Each month, a snapshot is tagged as a new MINOR release.
Versioning
Releases use the MAJOR.MINOR.PATCH scheme. Monthly snapshots increment
MINOR; PATCH is typically 0. Major releases are rare (years apart) and
signal significant architectural changes that may require updates to container
managers (Containerd, CRI-O) or other infrastructure. Breaking changes in
MINOR releases are avoided where possible, but may occasionally occur as
features are deprecated or removed.
No Stable Branches
The Kata Containers project does not maintain stable branches (see
#9064).
Bug fixes land on main and ship in the next monthly snapshot rather than
being backported. Downstream projects that need extended support or compliance
certifications should select a monthly snapshot as their stable base and manage
their own validation and patch backporting from there.
Release Process
Bump the VERSION and Chart.yaml file
When the kata-containers/kata-containers repository is ready for a new release,
first create a PR to set the release in the VERSION file and update the
version and appVersion in the
Chart.yaml file and
have it merged.
Lock the main branch
In order to prevent any PRs getting merged during the release process, and slowing the release
process down, by impacting the payload caches, we have recently trailed setting the main
branch to read only whilst the release action runs.
Note
Admin permission is needed to complete this task.
Wait for the VERSION bump PR payload publish to complete
To reduce the chance of need to re-run the release workflow, check the
CI | Publish Kata Containers payload
once the VERSION PR bump has merged to check that the assets build correctly
and are cached, so that the release process can just download these artifacts
rather than needing to build them all, which takes time and can reveal errors in infra.
Check GitHub Actions
We make use of GitHub actions in the
release
file from the kata-containers/kata-containers repository to build and upload
release artifacts.
Note
Write permissions to trigger the action.
The action is manually triggered and is responsible for generating a new
release (including a new tag), pushing those to the
kata-containers/kata-containers repository. The new release is initially
created as a draft. It is promoted to an official release when the whole
workflow has completed successfully.
Check the actions status page to verify all steps in the actions workflow have completed successfully. On success, a static tarball containing Kata release artifacts will be uploaded to the Release page.
If the workflow fails because of some external environmental causes, e.g. network timeout, simply re-run the failed jobs until they eventually succeed.
If for some reason you need to cancel the workflow or re-run it entirely, go first to the Release page and delete the draft release from the previous run.
Unlock the main branch
After the release process has concluded, either unlock the main branch, or ask
an admin to do it.
Improve the release notes
Release notes are auto-generated by the GitHub CLI tool used as part of our release workflow. However, some manual tweaking may still be necessary in order to highlight the most important features and bug fixes in a specific release.
With this in mind, please, poke @channel on #kata-dev and people who worked on the release will be able to contribute to that.
Announce the release
Publish in Slack and Kata mailing list that new release is ready.