Drop Go min patch version

[austinvazquez]

What I did

This PR addresses #13417 (comment)

Related issue

(not mandatory) A picture of a cute animal, if possible in relation to what you did

[thaJeztah]

:sadpanda: looks like some other dependency also set a patch version. Well 🤷‍♂️

[austinvazquez]

FWIW 1.24.3 is pretty common due to some breaking behaviors in 1.24.0-1.24.2.

[ndeloof]

I don't get the point here. What's wrong with 1.24.11? Why shall we use an older ref?

[glours]

The Go version defined in go.mod is currently used to determine which Go version our CI installs.

[thaJeztah]

The version in go.mod should follow MVS (Minimal Version Selection) and reflect the minimum required version of Go; similar to other dependencies.

For features introduced in a Go "minor" version, that would indeed require updating the version; i.e., if the project uses features that are only available in, say, go1.25, then the go.mod should be updated to go1.25.0, because it won't compile on older versions.

But for the patch version, that's not the case; patch versions should only contain bugfixes, not new features, so it's good to keep it at .0 ("any go1.24.x version can be used to compile this code"); for sure, users should normally use the latest patch release, but that's not up to compose to dictate that.

Currently, compose updates the patch version if compose itself choses to update to a newer version of go, but this caused issues with Azure (and others), who use a hardened version of Go; those versions usually go through some extra verification period before becoming available, but if compose bumps the minor version, it's not possible to build with any older patch version of Go.

[ndeloof]

.. as PR description suggests :)

[thaJeztah]

current versions of go no longer allow omitting the .<patch> entirely; usually it would be set to .0, but in this specific case, go1.24.0, go124.1 and go1.24.2 were broken, so there was a legit reason for some projects to not allow using them.

[ndeloof]

right.
I'm fine we change go.mod then, but CI workflow must be updated so we run with latest

[vincentbernat]

current versions of go no longer allow omitting the .<patch> entirely; usually it would be set to .0, but in this specific case, go1.24.0, go124.1 and go1.24.2 were broken, so there was a legit reason for some projects to not allow using them.

This is not true. The requirement you mention is for the toolchain directive. 1.24 is a valid for the go directive as it is a "language version". See https://go.dev/doc/toolchain#version.

[thaJeztah]

Oh, you're right, I misremembered! I know I tried really hard to keep those patch versions out, but at some point was no longer able to; looking at the moment I had to add it on Moby, it was this commit; moby/moby@36549fb and it was indeed because a dependency forced our hands, not Go itself.

The commit in golang.org/x/mod that added it, is actually interesting; looks like they did as workaround for a bug in Go 1.21 which DID cause omitting the patch version to break golang/mod@3afcd4e

go.mod: set go version to 1.22.0

The go verison was set to 1.22 but on Go versions 1.21.0 up to 1.21.10,
the toolchain upgrade logic will try to download the release "1.22",
which doesn't exist. Go 1.21.11+ incorporates CL 580217 (cherry-picked
in CL 583797) and will download 1.22.0, so it should be fine, but set
1.22.0 to allow the upgrade for users with older local toolchains.

I just tried again if it's possible to omit, but it looks indeed that if any dependency specifies a version with a patch version, there's no way to undo that;

cat go.mod
module example.com/foo

go 1.22

require golang.org/x/mod v0.21.0

cat main.go
package main

import "golang.org/x/mod/modfile"

func main() {
	var _ = modfile.GoVersionRE
}

go run main.go
go: updates to go.mod needed; to update it:
	go mod tidy

go mod tidy
cat go.mod
module example.com/foo

go 1.22.0

require golang.org/x/mod v0.21.0

Relevant portion there (https://go.dev/doc/toolchain#version) is this (so "1.21" includes pre-releases, whereas "1.21.0" excludes them (1.21.0 > 1.21));

Any two Go versions can be compared to decide whether one is less than, greater than, or equal to the other. If the language versions are different, that decides the comparison: 1.21.9 < 1.22. Within a language version, the ordering from least to greatest is: the language version itself, then release candidates ordered by R, then releases ordered by P.

For example, 1.21 < 1.21rc1 < 1.21rc2 < 1.21.0 < 1.21.1 < 1.21.2.

Before Go 1.21, the initial release of a Go toolchain was version 1.N, not 1.N.0, so for N < 21, the ordering is adjusted to place 1.N after the release candidates.

For example, 1.20rc1 < 1.20rc2 < 1.20rc3 < 1.20 < 1.20.1.

[thaJeztah]

LGTM (but not a maintainer)

[glours]

Blocking this operation until we are certain that it will have no potential impact on continuous integration.

[ndeloof]

Our CI set go version used based on go.mod (https://github.com/docker/compose/blob/main/.github/workflows/ci.yml#L201-L204) so this would mean we run CI with an older go runtime, with some potential security concerns

[ndeloof]

see https://github.com/docker/compose/actions/runs/19905648337/job/57061050009?pr=13418#step:8:23

[austinvazquez]

I took another look into this. actions/setup-go check-latest feature requires .0 patch; however, a dependency is requiring Go 1.24.3 due do broken toolchains 1.24.0-1.24.2.

As a workaround, I have updated actions/setup-go to v6 which added the ability to specify the toolchain version through .go-version files. So now the toolchain version can be bumped for CI regularly while maintaining a minimum version in go.mod.

WDYT? @ndeloof, @glours, @thaJeztah

[ndeloof]

LGTM
I wonder we could get GO_VERSION build arg set from this .go-version file to avoid value being hard-coded in Dockerfile