Skip to content
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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Update Go to 1.22 #4645

wants to merge 1 commit into from

Conversation

retornam
Copy link
Contributor

@retornam retornam commented Feb 13, 2024

Updates go.mod to version 1.22

Signed-off-by: Raymond Etornam < retornam@users.noreply.github.com >

Updates go.mod to version 1.22

Signed-off-by: Raymond Etornam <retornam@users.noreply.github.com>
Copy link
Member

@AkihiroSuda AkihiroSuda left a 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

go 1.21
go 1.22
Copy link
Member

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

Copy link
Member

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).

Copy link
Member

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.2 moby#46982.
  • I think docker compose also ran into issues
  • And if I'm not mistaken; Docker Desktop code also failed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants