• 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).
• Test the latest supported Kubernetes version (minor, ex: 1.31). However, all actively supported versions (minor, ex: 1.31, 1.30, 1.29) will be mentioned in the documented for the recommended versions, but it doesn’t mean they are the only supported versions. Longhorn supports all versions equal to or after minimum version (1.21 now).

  Here's an example:
  Longhorn's supported versions are v1.6, v1.7 and v1.8.
  Kubernetes' supported versions v1.29, v1.30 and v1.31 (https://endoflife.date/kubernetes)

Then, we will test the next Longhorn feature and patch releases on Kubernetes v1.31 and set the recommended Kubernetes to v1.31, v1.30 and v1.29.

• 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.

• Ensure that all shared libraries remain compatible with all actively supported releases, particularly Kubernetes libraries.
  • For example, go-common-libs should use library versions (ex: kube-api) compatible with those used in the 1.6.x components if the actively supported branches are 1.7.x and 1.6.x, as 1.6.x is the oldest supported branch.
• Once the oldest supported branch reaches EOL, it is acceptable to update dependencies that may introduce incompatibilities.

• 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 LTS 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.