clarify patch/minor version upgrade process

[liggitt]

Follow up from #11060, tracked in #12329

Tested/supported upgrade process for patch releases and minor releases is not clear in user-facing documentation:

• should we add requirements (or at least a strong recommendation) to be at latest patch version of 1.x prior to upgrades, and upgrade to latest patch version of 1.x+1 (since that is what we test, and what we can fix if broken)? @kubernetes/sig-architecture-pr-reviews @kubernetes/sig-release @kubernetes/sig-cluster-lifecycle-pr-reviews @kubernetes/sig-testing

Page to Update:
https://kubernetes.io/docs/setup/version-skew-policy/

[fabriziopandini]

+1 for adding strong raccomdation to be at latest patch version of 1.x prior to upgrades, and upgrade to latest patch version of 1.x+1

[neolit123]

/assign @timothysc @luxas @roberthbailey
sig-cluster-lifecycle: hello, we need feedback and approval for the proposals in this ticket from chairs with respect to LTS.

[roberthbailey]

I think a strong recommendation is ok; I don't think there should be a requirement. In some cases a provider may want to jump consumers between specific versions for upgrades that have been well tested, and if we make it a requirement to pick the latest patch version that may actually make it more difficult to qualify and upgrade clusters (because the qualification would reset each time a patch was cut).

[imkin]

/wg lts

[imkin]

Should this be based on the existing upgrade tests we have?

/assign

[sftim]

/language en