>Run the previous version of the cli in a container on your local machine.

I'd rather get out of IT and go into farming is this is considered a valid recourse.

May I join you?

This is both very clever and horrifying. This obviously works for development but doing a rolling update of your fleet is stressful without the additional wrinkle of progressively updating which tool you need to inspect or control that fleet.

Or, you know, just set `DOCKER_API_VERSION` to the version of the engine you're interacting with.

If it has the capability to communicate cross-version, it should just do that, instead of displaying an error message that /doesn't/ point you to `DOCKER_API_VERSION`.

Not doing so is a perfectly defensible decision. Not informing the user of the environment variable, however, is indeed a fairly awful mistake.

Are we the only two people who know this??

I certainly hope not. It's literally the first environment variable listed in the Docker CLI reference doc: https://docs.docker.com/engine/reference/commandline/cli/

You literally just proved his point.

I don't think he was arguing against it.

It's so hard to tell. I hope they were joking.

I'm not sure that I did. Let's expand out my point to see if I'm on the same page as the replies here.

1. TFA complains that versions of servers require corresponding client tools to be installed.

2. TFA says he loves docker in dev, but not in prod.

3. I state (omitting many steps): install the latest docker in your dev environment (or wherever you're connecting to prod), spin up a small docker image to run the appropriate version cli. This is cheap, easy, easy to understand why it works, consistent with points 1 and 2.

What am I missing?