ci failure for docs-upstream workflow is not related: #2269

General: should it be --buildkitd-x or --buildkit-x ?

I don't think we would expect buildx to refer to buildkit as anything other than a daemon. So maybe the d can be removed. I think it would make it easier to remember.

Hum I think buildkitd is the correct assumption as we are passing them to the daemon. Would also avoid deprecating buildkitd-flags but I agree for casual users buildkit is well-known. On the other hand, someone setting these flags knows what he's doing.

Should we keep the old flags as hidden / deprecated for 1 .. 2 releases so that we can print a meaningful error if someone is using these? (didn't fully read through the diff, so perhaps we have something for that).

Should we keep the old flags as hidden / deprecated for 1 .. 2 releases so that we can print a meaningful error if someone is using these? (didn't fully read through the diff, so perhaps we have something for that).

@thaJeztah Yes we keep config as hidden: https://github.com/docker/buildx/pull/2268/files#diff-e163527133bf99ae0eee4eacce5a81fd349ab589b9e85c205cba4618c5562305R113-R116

This is similar to https://github.com/docker/cli/blob/1443014cbd604b460548a7729ec8ec510a5dbc5d/cli/command/container/opts.go#L247-L250

Ah, thanks! Are we planning to officially deprecate the old one? (in that case, we could consider printing a deprecation warning when used, which can be "non-fatal" for now, but made "fatal" in a future release).

Ah, thanks! Are we planning to officially deprecate the old one? (in that case, we could consider printing a deprecation warning when used, which can be "non-fatal" for now, but made "fatal" in a future release).

Fine to keep it imo and I don't think the cli prints such warning atm for docker run --net-alias ... for example?

Needs follow-up on https://github.com/crazy-max/docker-setup-buildx-action