On every release we need to take care to stay compatible on available Golang Builder and Kubernetes/OpenShift Go Modules. This card is dedicated to the hygiene tasks being executed once per release. Upgrades to consider:

The table above provides a matching of the required repositories to upgrade separately (See sub-tasks). Instructions to consider:

1. For Golang upgrades, the selected Golang version is the one used to build and release the kubernetes version used in the next OpenShift release (e.g. go1.20 used for k8s 1.26 and OpenShift 4.13)
   1. For all repositories spanning multiple releases (e.g. operands) we should consider keeping the go-directive in the go mod file to the previous Golang release (e.g. go 1.19). Sometimes it happens that the newest Golang compiler for the next OpenShift release is not officially released yet. Leaving the directive to the previous Golang release enables building active z-streams with their respective production golang compiler.
2. For Go Modules upgrades:
   1. The client-go, api-machinery, apiserver modules should match the same k8s dependency used in the next OpenShift release (e.g. k8s 1.26 used for OpenShift 4.13)
   2. The openshift/api module should match the next OpenShift release branch (e.g. release-4.13)
   3. The controller-runtime module should match the operator-sdk recommendation. (See operator-sdk upgrade docs)
3. For SDK upgrades:
   1. The Operator-SDK mandates a comprehensive upgrade documentation

Developer Notes

1. Link all Pull and Merge requests for accomplishing the upgrades in this single task and NOT on the subtasks.
2. Consider that changing golang builders require changes on upstream repositories, the OpenShift release repository and midstream repositories