From 6e03a95730ef711afd725dcb161e13293ed7fa8e Mon Sep 17 00:00:00 2001 From: Zvonko Kaiser Date: Fri, 16 Jan 2026 00:23:37 +0000 Subject: [PATCH 1/2] doc: Update Release Process Add how Kata is doing the rolling release. Signed-off-by: Zvonko Kaiser --- docs/Release-Process.md | 24 +++++++++++++++++++++--- 1 file changed, 21 insertions(+), 3 deletions(-) diff --git a/docs/Release-Process.md b/docs/Release-Process.md index 4eb15e3f5a..0234814e05 100644 --- a/docs/Release-Process.md +++ b/docs/Release-Process.md @@ -22,9 +22,27 @@ both** and which **changes the behavior from the previous release** (incompatibl 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. -**Important** : the Kata Containers project doesn't have stable branches (see -[this issue](https://github.com/kata-containers/kata-containers/issues/9064) for details). -Bug fixes are released as part of `MINOR` or `MAJOR` releases only. `PATCH` is always `0`. +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](https://github.com/kata-containers/kata-containers/issues/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 From 7f662662cfdb803a757b38790403fff7b8581606 Mon Sep 17 00:00:00 2001 From: Zvonko Kaiser Date: Fri, 16 Jan 2026 00:25:22 +0000 Subject: [PATCH 2/2] lint: Fix 80 char column size Make markdownlint happy Signed-off-by: Zvonko Kaiser Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --- docs/Release-Process.md | 68 +++++++++++++++++------------------------ 1 file changed, 28 insertions(+), 40 deletions(-) diff --git a/docs/Release-Process.md b/docs/Release-Process.md index 0234814e05..cd30799e83 100644 --- a/docs/Release-Process.md +++ b/docs/Release-Process.md @@ -1,26 +1,12 @@ # 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](http://semver.org/) 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. +## Release Model Kata Containers follows a rolling release model with monthly snapshots. New features, bug fixes, and improvements are continuously integrated into @@ -48,28 +34,31 @@ their own validation and patch backporting from there. ### 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`](./../VERSION) file and update the -`version` and `appVersion` in the -[`Chart.yaml`](./../tools/packaging/kata-deploy/helm-chart/kata-deploy/Chart.yaml) file and -have it merged. +When the `kata-containers/kata-containers` repository is ready for a new +release, first create a PR to set the release in the [`VERSION`](./../VERSION) +file and update the `version` and `appVersion` in the +[`Chart.yaml`](./../tools/packaging/kata-deploy/helm-chart/kata-deploy/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. +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 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](https://github.com/kata-containers/kata-containers/actions/workflows/payload-after-push.yaml) +To reduce the chance of need to re-run the release workflow, check the [CI | +Publish Kata Containers +payload](https://github.com/kata-containers/kata-containers/actions/workflows/payload-after-push.yaml) 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. +rather than needing to build them all, which takes time and can reveal errors in +infra. ### Check GitHub Actions @@ -81,11 +70,10 @@ 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. +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](https://github.com/kata-containers/kata-containers/actions) to verify all @@ -93,12 +81,13 @@ steps in the actions workflow have completed successfully. On success, a static tarball containing Kata release artifacts will be uploaded to the [Release page](https://github.com/kata-containers/kata-containers/releases). -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 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](https://github.com/kata-containers/kata-containers/releases) and -delete the draft release from the previous run. +If for some reason you need to cancel the workflow or re-run it entirely, go +first to the [Release +page](https://github.com/kata-containers/kata-containers/releases) and delete +the draft release from the previous run. ### Unlock the `main` branch @@ -108,9 +97,8 @@ 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. +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.