I would like to discuss the future dependency upgrade strategy. In #11555, it was mentioned that some users were confused by the issue of dependency downgrades after an upgrade.

Kubespray’s version number is updated following K8s upgrades (e.g., K8s 1.28 corresponds to Kubespray 2.24, K8s 1.29 corresponds to Kubespray 2.25, K8s 1.30 corresponds to Kubespray 2.26, and so on). After the release, a release-2.xx branch will appear. If release-2.24 does not include K8s 1.29, the dependencies for release-2.24 should not exceed version 2.25.0.

I have two potential approaches to avoid the downgrade issue after upgrades:

1. Avoid proactively upgrading the dependencies of the release-2.xx branch unless a critical issue requires an urgent fix (with minimal upgrade impact). Otherwise, do not upgrade the versions after the branch is cut from the release. The advantage of this approach is that it maintains the original upgrade path, which is more intuitive for users. Any minor issues can be pointed out in the release notes under “action required.”
2. Proactively upgrade the dependencies of the release-2.xx branch, but ensure the upgrade path is clearly defined to prevent downgrades (e.g., 2.24.3 -> 2.25.1 rather than 2.24.3 -> 2.25.0 -> 2.25.1).

If you have any thoughts, feel free to discuss!

@yankay @mzaian @VannTen @ant31