Repository navigation
docker/compose/v5 will not compile with v29.3.0+incompatible #6877
Description
Description
Compiling with v29.3.0+incompatible produces compilation error when including github.com/docker/compose/v5 v5.1.1.
../go/pkg/mod/github.com/docker/cli@v29.3.0+incompatible/cli/command/container/tty.go:63:23: cannot range over 10 (untyped int constant): requires go1.22 or later (-lang was set to go1.16; check go.mod)
This makes it impossible to use docker/compose as you need docker/cli to initialize the ComposeService
Reproduce
I have a very small reproduce of this: https://github.com/pedantic79/docker-bug/tree/main
Where the compilation error will occur.
go.mod contains
require (
github.com/docker/cli v29.3.0+incompatible
github.com/docker/compose/v5 v5.1.1
)
main.go contains
func main() {
dockerCli, _ := command.NewDockerCli()
composeService, _ := compose.NewComposeService(dockerCli)
fmt.Println(composeService) // avoid compiler complaining about unused variable
}
Expected behavior
Program to compile
docker version
N/Adocker info
N/AAdditional Info
I can pin to v29.2.1+incompatible and that fixes the issue, as that version doesn't use the for retry := range 10 that was introduced in v29.3.0+incompatible
Activity
thaJeztah commentedon Mar 25, 2026
Thanks for reporting; this is a duplicate of #6852, and fixed in #6854, which will be in the upcoming patch release.
pedantic79 commentedon Mar 25, 2026
@thaJeztah I can open a new bug for this, but the latest commit (7922984) will produce a similar but different bug
It does build correctly with (5d8cc2c) new commits seem to introduce this.
thaJeztah commentedon Mar 25, 2026
Ugh; that's on master I think, or also on the 29.x branch? Let me double check (I have a PR pending to validate as part of CI while we're still in this horrible "not a real module" situation)
pedantic79 commentedon Mar 25, 2026
On master. Just checked with (9637f1b)
pedantic79 commentedon Mar 25, 2026
(c2be9cc) On 29.x branch is okay.
thaJeztah commentedon Mar 25, 2026
Thanks! Yes, I see it failing in #4723 (which is good news that it works 😂). It's really whack-a-mole with Go downgrading go language versions for individual files.
pedantic79 commentedon Mar 25, 2026
Yep. I can keep my code pinned to the last working version. Just wanted to make sure it's known so we don't have another broken version released in the future.
thaJeztah commentedon Mar 25, 2026