mirror of https://github.com/kata-containers/kata-containers.git synced 2026-04-02 18:13:57 +00:00

Files

Manuel Huber 4afb55154a docs: Update release process notes

Update the Release-Process.md file with some clarifications on the
release process.

Signed-off-by: Manuel Huber <manuelh@nvidia.com>

2026-03-19 15:14:23 -07:00

4.7 KiB

Raw Blame History

How to do a Kata Containers Release

This document lists the tasks required to create a Kata Release.

Requirements

GitHub permissions to run workflows.

Release Model

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

Lock the `main` branch and announce release process

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 trialed setting the main branch to read-only. Once the kata-containers/kata-containers repository is ready for a new release, lock the main branch until the release action has completed. Notify the #kata-dev Slack channel about the ongoing release process. Ideally, CI usage by others should be reduced to a minimum during the ongoing release process.

Note

Admin permission is needed to lock/unlock the main branch.

Bump the `VERSION` and `Chart.yaml` file

Create a PR to set the release in the VERSION file and to update the version and appVersion fields in the Chart.yaml file. Temporarily unlock the main branch to merge the PR.

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.

Trigger the `Release Kata Containers` GitHub Action

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.

4.7 KiB Raw Blame History