Change:
Follow up from , tracked in 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 prior to upgrades, and upgrade to latest patch version of (since that is what we test, and what we can fix if broken)? Page to Update:
+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
/assign sig-cluster-lifecycle: hello, we need feedback and approval for the proposals in this ticket from chairs with respect to LTS.
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).
/wg lts
Should this be based on the existing upgrade tests we have? /assign
/language en
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/kind feature /priority backlog
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen /remove-lifecycle rotten /lifecycle frozen
Reopened this issue. <detailsIn response to : /reopen /remove-lifecycle rotten /lifecycle frozen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted

Discussion:
The supported version skew between components has implications on the order in which components must be upgraded. This section describes the order in which components must be upgraded to transition an existing cluster from version **{{< skew currentVersionAddMinor -1 >}}** to version **{{< skew currentVersion >}}**. <ins> Optionally, when preparing to upgrade, the Kubernetes project recommends that you do the following to benefit from as many regression and bug fixes as possible during your upgrade: *  Ensure that components are on the most recent patch version of your current minor version. *  Upgrade components to the most recent patch version of the target minor version. For example, if you're running version {{<skew currentVersionAddMinor -1>}}, ensure that you're on the most recent patch version. Then, upgrade to the most recent patch version of {{<skew currentVersion>}}. </ins> ### kube-apiserver Pre-requisites: