Add "supported releases" language to versioning.md #17806
Conversation
ikehz
added
area/api
|
Labelling this PR as size/S |
k8s-github-robot
added
the
size/S
|
GCE e2e test build/test passed for commit a01eba5. |
|
|
||
| We expect users to stay reasonably up-to-date with the versions of Kubernetes they use in production, but understand that it may take time to upgrade. | ||
|
|
||
| We expect users to be running approximately the latest patch release of a given minor release; we often include critical bug fixes in [patch releases](#patch-release), and so encourage users to upgrade as soon as possible. Furthermore, we expect to "support" three minor releases at a time. With minor releases happening approximately every three months, that means a minor release is supported for approximately nine months. For example, when v1.3 comes out, v1.0 will no longer be considered "fit for use": basically, that means that the reasonable response to the question "my v1.0 cluster isn't working," is, "you should probably upgrade it, (and probably should have some time ago)". |
There was a problem hiding this comment.
We need to spell out what "support" means at least a little. For example, does it imply that we continue to make patch releases?
|
@wonderfly I intentionally left it vague-with-judgement-guidelines because we don't honestly know what the pain is going to be like in 6 months for 1.0 users. With 1.1 out, we're finding unexpected issues that are causing us to rethink things; I don't want to promise something we won't deliver on. That said, I clarified the language a bit. If others think we should make more concrete promises, I'm open to suggestions. |
|
GCE e2e test build/test passed for commit 5ce2d70. |
|
LGTM |
ghost
closed this
ghost
added
the
lgtm
ghost
reopened this
|
@k8s-bot e2e test this please |
|
@k8s-bot unit test this please |
|
Automatic merge from submit-queue |
Auto commit by PR queue bot
|
GCE e2e test build/test passed for commit 5ce2d70. |
Auto commit by PR queue bot
Add language in our versioning policy for "supported releases" that is in line with GKE's policy for upgrades & downgrades for last three minor versions.
@kubernetes/goog-testing A big part of the motivation for this is that we can't reasonably expect to test more than three releases at a time; got to draw the line somewhere, and this seems like a reasonable place to draw it: we'll be running tests for four branches (!) at a time: e.g. v1.0, v1.1, v1.2, and master when v1.2 is the latest release.
cc @quinton-hoole @wonderfly @kubernetes/goog-gke