From 4142e424653612959aa51f115cb675b0d63dc4da Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Fabiano=20Fid=C3=AAncio?= Date: Tue, 18 May 2021 15:28:41 +0200 Subject: [PATCH] docs: Don't mention 1.x components as part of the stable branch strategy MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Let's slightly rewrite the text to ensure users of 2.x that never had contact with kata-containers 1.x would be able to understand the sentences. Signed-off-by: Fabiano Fidêncio --- docs/Stable-Branch-Strategy.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/Stable-Branch-Strategy.md b/docs/Stable-Branch-Strategy.md index d10e1ab75..84a9779f5 100644 --- a/docs/Stable-Branch-Strategy.md +++ b/docs/Stable-Branch-Strategy.md @@ -143,10 +143,10 @@ maturity, we have increased the cadence from six weeks to twelve weeks. The rele ### Compatibility Kata guarantees compatibility between components that are within one minor release of each other. -This is critical for dependencies which cross between host (runtime, shim, proxy) and +This is critical for dependencies which cross between host (shimv2 runtime) and the guest (hypervisor, rootfs and agent). For example, consider a cluster with a long-running deployment, workload-never-dies, all on Kata version 2.1.3 components. If the operator updates the Kata components to the next new minor release (i.e. 2.2.0), we need to guarantee that the 2.2.0 -runtime still communicates with 2.1.3 agent within workload-never-dies. +shimv2 runtime still communicates with 2.1.3 agent within workload-never-dies. Handling live-update is out of the scope of this document. See this [`kata-runtime` issue](https://github.com/kata-containers/runtime/issues/492) for details.