Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update readme compatability matrix for 1.10 #5484

Merged
merged 1 commit into from
Aug 16, 2018
Merged

Update readme compatability matrix for 1.10 #5484

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 7 additions & 6 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -84,12 +84,13 @@ Kubernetes version.

#### Compatibility Matrix

| kops version | k8s 1.5.x | k8s 1.6.x | k8s 1.7.x | k8s 1.8.x | k8s 1.9.x |
|--------------|-----------|-----------|-----------|-----------|-----------|
| 1.9.x | Y | Y | Y | Y | Y |
| 1.8.x | Y | Y | Y | Y | N |
| 1.7.x | Y | Y | Y | N | N |
| 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 |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I agree both thoughts. I think the readme isn't the right place to begin considering this as it takes more time to denote deprecation and decide the course of action.

I've opened an issue to track and figure out if and how we should consider this.

Thanks @justinsb and @rdrgmnzs!

| 1.9.x | Y | Y | Y | Y | Y | N |
| 1.8.x | Y | Y | Y | Y | N | N |
| 1.7.x | Y | Y | Y | N | N | N |
| 1.6.x | Y | Y | N | N | N | N |

Use the latest version of kops for all releases of Kubernetes, with the caveat
that higher versions of Kubernetes are not _officially_ supported by kops.
Expand Down