Bump k8s.io/client-go from 0.35.4 to 0.36.0

[dependabot]

Bumps k8s.io/client-go from 0.35.4 to 0.36.0.

Commits

• 1d95f02 Update dependencies to v0.36.0 tag
• f22a53e Merge remote-tracking branch 'origin/master' into release-1.36
• a948641 Update github.com/moby/spdystream from v0.5.0 to v0.5.1
• 7e44ffc Add Workload-Aware Preemption fields to Workload and PodGroup APIs
• df2d882 Merge pull request #136989 from nojnhuh/podgroup-resourceclaim
• 4eece52 Workload API: PodGroup ResourceClaims (KEP-5729)
• 3d35c51 Merge pull request #137190 from everpeace/KEP-5491-alpha
• 0434117 Merge pull request #137028 from nmn3m/feature/dra-resource-pool-status
• ba785be Drop CSR analogy, mark ObjectMeta +required,reduce limits (maxItems=500, maxL...
• 4a9c878 Add ResourcePoolStatusRequest API types and generated code
• Additional commits viewable in compare view

[dirkmueller]

I'm not sure we should be taking a 1.36 / go 1.26 update at this time.

[ipetrov117]

I'm not sure we should be taking a 1.36 / go 1.26 update at this time.

@dirkmueller, fwiw, this was not intended to be merged for 0.6. However, I am interested in what is your reasoning behind wanting to postpone it.

IIRC, we agreed that LCM will follow the go version of elemental and with this PR elemental is going from 1.25.6 -> 1.26.0. So shouldn't LCM follow?

Regarding taking the 1.36 libraries, I do not see a problem in using them, as 1.36 is within the Kubernetes version skew for 1.35 clusters, which IIUC are the clusters that we will be shipping for 0.6.

That said, I do agree that changing these versions right before 0.6 is not desirable and I do not advocate on doing it, but also at the same time I do not think that they will cause much trouble.

Also, side question, if we are going to enforce 1.25.6 go version for 0.6, should this enforcement also be applied to the elemental repository, or is this something specific to LCM?

[dependabot]

Superseded by #32.