make: use GO_VERSION=1 for release builds

[cyphar]

We have forgotten to bump GO_VERSION in our Dockerfile several times
when doing releases from old release branches, leading to use using
EOL'd Go versions for releases. We should just always use the latest
version when building our release artefacts.

Fixes #4969
Signed-off-by: Aleksa Sarai [email protected]

[akhilerm]

There can be a case where CI is not updated, but still the release happens with the latest versions. I dont think we should be in such a situation,also we had issues like #4234 in the past.

[cyphar]

I did think about that, but I think that the current situation we have (where we can easily forget to update old versions) is a far more common problem than the case where we know that runc is having issues with a new version (in which case, it's still easy to use a different GO_VERSION manually if we go with @AkihiroSuda's suggestion).

[cyphar]

That being said, I do somewhat question how important it is if our release binaries are built with EOL'd Go versions -- we don't rebuild old release binaries, so every binary we release is destined to have been built by an EOL'd compiler (or an older release with a security issue) at some point.

I guess trying to go for the newest one from the start is the least bad option, but I do wonder how helpful this is in general.

[kolyshkin]

Maybe we should also add 'stable' (and 'oldstable') to CI, too (perhaps only in release-* branches, not in main).

Otherwise we may end up running tests with e.g. Go 1.23 but building release binaries using Go 1.25. I remember @thaJeztah had his reasons to not do that, but I don't remember what was it exactly.

[thaJeztah]

Things I'm on the fence on;

• With this change, the version in the Dockerfile (and elsewhere) is not updated; for most of our dependencies, we explicitly have the version used captured in source-control (i.e., I could open the tag, and see what was used); this also makes updating the go version an explicit action, while (through the --build-tag or otherwise), it would still allow packagers to override the version.
• IIUC, this change would not change CI to be using these versions, which means that a release would use a different version of Go than was tested; potentially hiding subtle changes in Go that we know are sometimes causing regressions.

Would we have some check in CI that the version of Go used is matching the current patch release of the minor version used in the branch, and that minor version to not be an EOL version at time of release? (Which may be "oldstable" for specific branches)?