Update readme compatability matrix for 1.10 #5484
Conversation
k8s-ci-robot
added
cncf-cla: yes
|
Putting a hold on this until we're ready to release 1.10 /hold |
k8s-ci-robot
added
the
do-not-merge/hold
|
/area documentation |
| | 1.6.x | Y | Y | N | N | N | | ||
| | kops version | k8s 1.5.x | k8s 1.6.x | k8s 1.7.x | k8s 1.8.x | k8s 1.9.x | k8s 1.10.x | | ||
| |--------------|-----------|-----------|-----------|-----------|-----------|------------| | ||
| | 1.10.x | Y | Y | Y | Y | Y | Y | |
There was a problem hiding this comment.
I know the README says kops is intended to be backward compatible. but is there a point where we would no longer support a older version of k8s with the newest version of Kops? The idea behind that being that we would then be able to clean up older code. I've also not see anyone testing the older versions (such as 1.5.x) so new code may not actually support those versions?
Just a passing thought.
There was a problem hiding this comment.
It's a balance between the cost of carrying the old branches vs breaking people's clusters (even if those clusters are running versions of k8s that are unsupported).
So far the cost hasn't been too high, but if we came to a point where the cost was high I could see that we would start a deprecation procedure or tell people that they had to use an older version of kops and that they wouldn't be getting bugfixes.
As you say though, it's certainly not a good idea to run e.g. k8s 1.5 with kops today, because it doesn't have nearly the same testing
There was a problem hiding this comment.
|
/hold cancel |
k8s-ci-robot
removed
the
do-not-merge/hold
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: mikesplain, rdrgmnzs The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest |
No description provided.