-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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 Go to 1.22 #4645
Update Go to 1.22 #4645
Conversation
9cb92cb
to
b07cc44
Compare
Updates go.mod to version 1.22 Signed-off-by: Raymond Etornam <[email protected]>
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.
Go 1.22 seems still unstable, although the issue seems specific to specific version of glibc
b07cc44
to
f6f2ec2
Compare
go 1.21 | ||
go 1.22 |
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.
In addition to the above, we should always try to support both latest and latest-1, and not enforce (in this case) go1.22
Perhaps we can construct a matrix for at least 1.22
and 1.21` (latest and latest-1, per Go's recommendations) to be tested in CI
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.
👀 not necessarily sure I understand the point in upgrading then.
If we want to support the last two versions, we can't take advantage of any of the new features in the latest version (or rely on any of the new behavior, like the loop-copying).
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'm not against updating Go versions in general, but know that we have a complex stack and dependency tree, and with most Go releases we discover sometimes "obscure" bugs / regressions, as parts of the stack at least may be using parts in Go that the Go maintainers did not consider. From that perspective, I usually prefer not to jump on "latest is greatest" on day 1. It's possible that BuildKit itself does not hit those bugs/regressions, but knowing that BuildKit is also used as a module/library in various code-bases, which may hit these issues, and may not be updating to go1.22 yet, it's good to preserve backward compatibility (If there's features in newer go versions that really MUST be used with no other options for that, we could use those, but possibly stubs / backward code in place (go:xxx
build constraints).
It's good to have newer versions already tested in CI (which could be either adding to the test matrix, or a draft PR); I tend to open draft-PRs when Go starts doing RC's to get an early notice on regressions; ideally for those to be fixed before they reach GA, but frequently that's not a reality, and we need to wait for some patch releases first.
At least currently, we're aware of go1.22 not working with;
- runc
- Microsoft/go-winio (used by hcsshim); For go-winio, there's a patch merged, but not yet released; also see update to go1.22.6 moby#46982.
- I think
docker compose
also ran into issues - And if I'm not mistaken; Docker Desktop code also failed.
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 left it to go1.21 for now in #5059 but I don't necessarily think we need to wait 6 months every time before we can start using new Go features. But on the same time if we don't have a strict requirement to go1.22 atm then we don't need to enforce it yet either. For example I like the https://pkg.go.dev/cmp@master#Or in go1.22 and would expect we start using it soon in buildkit.
Carried to #5059 |
Updates go.mod to version 1.22
Signed-off-by: Raymond Etornam < [email protected] >