use standard TARGETARCH for architecture suffix #13496
Conversation
Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>
| # TODO: should just use standard arch | ||
| TARGETARCH=$([ "$TARGETARCH" = "amd64" ] && echo "x86_64" || echo "$TARGETARCH"); \ | ||
| TARGETARCH=$([ "$TARGETARCH" = "arm64" ] && echo "aarch64" || echo "$TARGETARCH"); \ | ||
| cp docker-compose* "/out/docker-compose-${TARGETOS}-${TARGETARCH}${TARGETVARIANT}$(ls docker-compose* | sed -e 's/^docker-compose//')" |
There was a problem hiding this comment.
This will probably need an update to the official docker image as well; it looks like it currently downloads binaries from GitHub; https://github.com/docker-library/docker/blob/d9bae6519a1b0a9c73fab9a859e0c5c5131b0176/29/cli/Dockerfile#L110-L140
Wondering if we should (to help transitioning) keep both variants for some time.
There was a problem hiding this comment.
we could, but this won't help us detect the places to require an update, as consumer won't notice the breaking change
There was a problem hiding this comment.
Agreed, it's better to just rip the bandaid off than double the storage in the hopes that somebody proactively notices, but I do appreciate the thought. 🫶
(If releases could have symlinks in their artifacts, perhaps I would feel differently, but they can't - eventually the bandaid has to come off and it might as well be sooner instead of later.)
There was a problem hiding this comment.
Yeah, that's reasonable; perhaps we should create a ticket and pin it on this repository for users that arrive here after they get a "not found" error.
(We still have a similar discussion to have for the static downloads from https://download.docker.com/mac/static/stable/, although I guess for those we could have a symlink / redirect)
I mostly was considering that this change may go out in a minor or patch release; if it's a patch release, then users may pay less attention to release notes. I guess it would've been great to make the change with the v5 major version update, but hindsight is a B.
We should also check if there's references to these in our docs; looks like there's at least one in this section; https://docs.docker.com/compose/install/linux/#install-the-plugin-manually
3 participants
What I did
use standard
TARGETARCHfor architecture suffix in released binariesthis enforces consistency with other Docker CLI plugins (buildx, buildx, scout, init ...)
note: this is a breaking change which may impact scripts downloading latest release. Anyway, this TODO is here for too long, better introduce a breaking change once and get a consistent user experience across docker repositories
Related issue
(not mandatory) A picture of a cute animal, if possible in relation to what you did