Let's write down a policy for go version updates
I'm not sure if we have written down the policy, but in our LLM-guided future it would be great to write down:
- When we update go minor versions (especially for backports)
- When we update other dependencies (and I suspect here we have a different policy for backports)
cc @hakman @rifelpet
I think a reasonable starting point is to have a kops release's go minor version match that of its k/k dependencies.
We could also upgrade all supported versions, including master, when k/k cherry-picks the new Go version. (unless there is some amazing feature that we want to use very fast).
Seem that's it's pretty hard to not bump Go. After some time, dependencies start pulling the latest k8s version and latest Go comes with it.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle rotten - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten