search

Arnavion / k8s-openapi

Rust definitions of the resource types in the Kubernetes client API
Apache License 2.0
373 stars 42 forks source link

Remove Kubernetes 1.16 and 1.17 #118

Closed jesperpedersen closed 2 years ago

jesperpedersen commented 2 years ago

Support for the following Kubernetes versions have been removed:

Signed-off-by: jesperpedersen jesper.pedersen@redhat.com

Arnavion commented 2 years ago

https://github.com/Arnavion/k8s-openapi/blob/master/CONTRIBUTING.md#cloud-offerings

1.18+ are still supported by some clouds.

In any case, I'm generally in no rush to drop versions unless there's some benefit gained, like some thing that is only different in these old versions such that dropping them simplifies the code generator. Eg the last time I dropped versions was in https://github.com/Arnavion/k8s-openapi/commit/bac3cf3b00055407d1232b2335b75031bf31a5aa.patch which allowed WatchEvents to always include BOOKMARK events.

On that note, there are many k8s_if_* macros in k8s-openapi-tests/resource.rs that could've been removed in your PR. In particular, if you restore 1.18+, then all the k8s_if_le_1_17! invocations can be deleted entirely.

jesperpedersen commented 2 years ago

Ok, I understand where you are coming from - and def agree that 1.16 and 1.17 can be removed based on your feedback.

However, if a vendor chooses to support an outdated Kubernetes release they can contribute to a branch within this repository with the necessary updates. Development platforms such as minikube and kind have already moved to Kubernetes 1.23 and keeping the code base as clear as possible will help new users understand where to start.

I can update this pull request with only removing 1.16 and 1.17 if you think that will be a good start.

Arnavion commented 2 years ago

However, if a vendor chooses to support an outdated Kubernetes release they can contribute to a branch within this repository with the necessary updates.

Sure, or I could make them not even do that, because it costs me nothing to keep old versions around.

keeping the code base as clear as possible will help new users understand where to start.

The hosted documentation is built against the latest version, and the documentation on the features does explain their purpose in targeting the lowest API version that the user expects to run against. If you want to tweak the documentation to make that clearer, go ahead, but I don't think users would be confused by just the existence of older versions.

I can update this pull request with only removing 1.16 and 1.17 if you think that will be a good start.

Yes. That's why I mentioned the macro invocations you can remove.

Arnavion commented 2 years ago

Also, the reason you didn't get errors from not removing those macro invocations is because you did not change both build.rs's, so make sure you do that too.

jesperpedersen commented 2 years ago

Updated.

Looks like most vendors will require Kubernetes 1.20 starting next month. Should I remove 1.18 and 1.19 as well ?

Arnavion commented 2 years ago

Looks like most vendors will require Kubernetes 1.20 starting next month. Should I remove 1.18 and 1.19 as well ?

I'm hoping to cut a release sooner than that, so not yet.

jesperpedersen commented 2 years ago

Sounds good to me :) 0.15.0: -1.16, -1.17, +1.24

jesperpedersen commented 2 years ago

Thanks !