Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion go.mod
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
module github.com/docker/compose/v5

go 1.24.11
go 1.24.3
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@ndeloof ndeloof Dec 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then go.mod should better just declare 1.24 without a patch version, as suggested by https://gitea.com/actions/setup-go#getting-go-version-from-the-gomod-file

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.. as PR description suggests :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


require (
github.com/AlecAivazis/survey/v2 v2.3.7
Expand Down