With the Latest Docker Engine v25.x the Version Selection Magic Based on the Call Option 'ver` Tags Results in Failing Calls

[kcq]

The Docker Engine v25.0 release deprecates the APIs below version 1.24 ( https://docs.docker.com/engine/deprecated/#deprecate-legacy-api-versions ).

The current dynamic version selection logic causes failures if you haven't configured an options field in the API call you are making with a big enough 'ver' tag value.

We can use (c *Client) BuildImage(opts BuildImageOptions) as an example: https://github.com/fsouza/go-dockerclient/blob/main/image.go#L537

It calls queryStringVersion to figure out the minimal API version based on the provided BuildImageOptions fields. Then it calls pathVersionCheck, which creates buildURL based either on the explicitly configured API version when the client was created or the minimal API version guessed by queryStringVersion.

If you set the Name and ForceRmTmpContainer fields in BuildImageOptions queryStringVersion will guess the minimal version to be 1.12 (because the ver tag for the ForceRmTmpContainer field in BuildImageOptions is set to 1.12 ). Then pathVersionCheck will create an API path with 1.12 if you don't create a versioned Client explicitly.

The go-dockerclient claims that if you don't specify an API version then the latest API version will be used, but it's not really the case here.

@fsouza curious what you think about this behavior and how you'd prefer to address it in the library. The docker/moby client has the NegotiateAPIVersion call ( https://github.com/moby/moby/blob/v25.0.1/client/client.go#L294 ) that's potentially relevant for this.

[fsouza]

Thanks for opening this issue and apologies for the delayed response.

I think we can try to adopt the same behavior as the official SDK. Also, I think it's kind of an accident that we don't use the latest version when it's not specified. I'm thinking of trying to fix that, but also understand that that has the potential to break many things. I'll poke around in the next couple of days!

[kcq]

Both sound like a good idea. For the second enhancement how about adding a client option to toggle the behavior to get latest version or to have the original version selection magic? Thank you for the library and no worries about the delays. Pretty sure you have enough on your plate and the open source work is personal time :)

[joesiewert]

@fsouza anything that can be done to move this one forward? Even though we are specifying an API version we seem to be running into this issue on image pulls.

[joesiewert]

I tested this again where the Docker API version is set to 1.43 when initializing the client. Despite this, still getting the error as soon as the client tries to pull an image:

API error (400): client version 1.21 is too old. Minimum supported API version is 1.24, please upgrade your client to a newer version

Does not seem like it's possible to upgrade beyond Docker 24.0.9 at this point.