Document Support Policy on Kueue Releases

[kannon92]

As Kueue matures, there is some questions on when Kueue decides that a release is no longer supported. I don't really know when we decide a release is no longer in support.

My hope would be some kind of documented policy on when we stop maintaining release branches and force people to use later versions.

[mimowo]

cc @mwielgus @tenzen-y @mwysokin @dgrove-oss

Good question, I think we generally support only the last released version, but not sure this is documented anywhere.

It may also be a bit tricky to set rigid rules because the release cadence isn't as fixed. In the past we had 1 to 4 months intervals between releases, which could be making some difference also.

[kannon92]

One rough proposal I talked with @tenzen-y about is maybe linking support to the k8s release version the APIs are based on. This does mean that we are supporting much longer release branches. Generally Kueue is pretty good about upgrading the k8s dependencies once the newest patch of the latest version is released (ie 1.32.1, we upgrade k8s release. Maybe that can be a release?).

For openshift, we offer LTS on k8s release branches and eventually we will end up not being able to support certain kueue releases as the skew increases but I think LTS for Kueue may be linked with the k8s version eventually. I would see folks wanting to run/support Kueue on 1.28 as long as 1.28 is still in support. It isn't clear to me what Kueue release we would support in this case.

[dgrove-oss]

Summarizing my input from the wg call today. Wearing my "consumer of Kueue" hat, the minimum expectation would be that at some point relatively soon we'd get into a steady state where there would always be a release of Kueue that is supported by this community that would work with each version of Kubernetes that is being supported by the Kubernetes community.

This doesn't mean that as a consumer of Kueue I expect the Kueue community to support every Kueue release on every supported version of Kubernetes. What I do expect is:

1. There is some well-defined structure of Kueue release streams (eg, fast and stable). Not every Kueue release needs to be a stable release.
2. The stable stream would have always a release that is supported by the Kueue community on each version of Kubernetes that is supported by the Kubernetes community.
3. If a cluster is running a supported version of Kubernetes, then the Kueue community supports upgrading Kueue "in place" on that cluster from the Nth to N+1 release in Kueue's stable release stream.