Version Update Policy
David Ko edited this page Jan 18, 2024
·
8 revisions
- Do not raise the minimum version of Kubernetes until our new features rely on a specific minimum K8s version. This is an example of how to select a new min K8s version when we have to bump it https://github.com/longhorn/longhorn/issues/3891#issuecomment-1131258472
- Continue mentioning the minimum version as usual (it's 1.21 now) but only test the actively supported K8s versions (1.26, 1.27, 1.28 now).
- This can provide QA with a clear idea of what they should test. Align with the upstream.
- Update documentation with all versions we support, but highlight the versions that will be verified in each release as an OS distribution.
- Continue updating the versions for new feature releases.
- Update the versions of maintained releases as needed, particularly for CVE resolution.
- Update Kubernetes client libraries independently of the minimum version. It was assumed to be backward-compatible.
- Continue updating the versions for new feature releases.
- Update the versions of maintained releases as needed, especially for CVE resolution.
- Continue updating the versions for new feature releases.
- Update the versions of maintained releases as needed, especially for CVE resolution.
- Distros to verify
- Ubuntu
- SLES
- SLE Micro
- RHEL
- Oracle Linux
- Rocky Linux
- Talos Linux
- To ensure efficient testing, we will be focusing on verifying the recent major/minor version (9) as our top priority. For instance, for Longhorn 1.6, we will prioritize testing RHEL 9.3 instead of 8.9 in v1.6. If there are requests to verify other versions in the future, we will address them as they come.
- The distros listed in the doc just mean they have been verified but doesn't mean we only support them. For the current verification design, we will base on internal testing capacity, so only keep SLES & SLE Micro up-to-date for actively supported release branches. However, for other non-SUSE distros, we will bump each distro to the latest version like what we did for 1.5 when doing a feature release (minor or major, dot 0 release). We will do the same for 1.6.