Update to Go 1.22 #2550
Update to Go 1.22 #2550
Conversation
| @@ -1,6 +1,6 @@ | |||
| module github.com/containers/image/v5 | |||
|
|
|||
| go 1.21.0 | |||
| go 1.22.5 | |||
There was a problem hiding this comment.
I have to think about this, I am not to happy about requiring a specific patch version. We may quickly end up moving faster than distros but I will look into it tomorrow.
There was a problem hiding this comment.
This comes from the sigstore dependencies, e.g. sigstore/sigstore#1786 sigstore/fulcio#1735 . In these instances we can hold them back, but it comes with the usual risks of a future vulnerability forcing us to update later at a hurry, or to fork to carry a backported fix.
For the record, there’s a parallel conversation about this issue in containers/podman#23289 .
There was a problem hiding this comment.
The problem around this is simple, we may end up moving faster than consumers.
The go 1.22 bump means no fedora 39 support already, if we start bumping the patch version we may require a newer version than in some distros. While we do have some upstream CI here we do not cover all the version we have to build on here, currently this CI setup does not use packit and we only test the latest fedora in cirrus I think so we easily break ourself in podman and buildah that have to build on fedora -1 and debian sid...
And we might break the packit tasks for centos stream/epel as well.
On every update we have to check all the versions in all the distros we care about to ensure it can still be build. I don't know how RHEL handles the golang versions but we certainly do not want to cut a new upstream releases for RHEL just to discover they cannot be build until golang is updated there.
IMO distros are responsible for shipping new golang with updated bug/security fixes, it seems strange for to require a specific patch version just because of a fix across all your consumers. It it not like go changes the behaviour on a patch release like they did with the for loop copy behavior in 1.22 which does require such an enforcement.
If a projects want to build it with a specific version they can use the toolchain directive which does not effect library users.
If these are the only dependencies where this done currently I would rather try to push back upstream. Though I understand that this can happy in any dependency at any time... I really hope it will not
And even worse this will become a gigantic PITA when backporting security fixes from such dependencies to LTS branches as these things need to happen fast but the golang update may not be so fast.
There was a problem hiding this comment.
Per discussion we accept this risk going forward so LGTM
Signed-off-by: Miloslav Trmač <[email protected]>
Signed-off-by: Miloslav Trmač <[email protected]>
Signed-off-by: Miloslav Trmač <[email protected]>
... and increase the jitter precision Signed-off-by: Miloslav Trmač <[email protected]>
|
LGTM |
Do not merge before we are certain the consumers can update.
Cc: @Luap99