This is my take on version comparison

[imp]

If this makes sense I'll add finding the best version if no --api-version provided

Related to #23

[clux]

I think this makes sense. It looks very similar to the code we have in discovery. I am sort of inclined to clean that up and make it public, but it's also not a particularly big deal to have this duplicated here initially.

[imp]

Quite similar indeed. So, let me know how would you like to proceed.

[clux]

I kind of thing it's ok to export Version from discovery and import it here.

The sort order is what we want, and while it's the opposite of what we want, it was chosen that way so we could .sort() and pick the first (as the most latest version): https://github.com/kube-rs/kube-rs/blob/120d0001ce58eb18ac59d2a9da1bf8514bc8058c/kube-client/src/discovery/apigroup.rs#L90-L95

[clux]

Probably need to add a line of documentation about the order in the public docs though - it's currently only in the tests.

Do you want to have a go at making a PR for this in kube-rs? It will make this slower to get out (we just released 0.65.0), so happy with some copy pasting from there in the mean time if you need this.

[imp]

Took me some time to get back to this. Sure, I can go via kube-rs - no need to duplicate non-obvious code.
So, if I understand correctly you would prefer to keep the implementation in kube-rs and just make it public (documented, etc), correct?

[clux]

Yes, I will try to move the Version struct into kube_core, and make it public there. Give me a couple of hours and I'll probably have a branch that we can depend on from here.

[clux]

There is a branch now in kube-rs/kube#764 which exposes Version under kube_core You can try to develop from that branch as a git dependency until it is released - should be a pretty light dependency now since it's only kube_core we need.

[imp]

superseded by #27