-
Notifications
You must be signed in to change notification settings - Fork 374
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update to Go 1.22 #2550
Merged
Merged
Update to Go 1.22 #2550
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per discussion we accept this risk going forward so LGTM