Release Binaries not to include Version

[driverpt]

Currently release binary names are including version, e.g.: buildx-<version>.<arch>

Is it possible to remove the -<version> so we can just do an unattended install via script?

e.g.:

wget -O /usr/lib/docker/cli-plugins/docker-buildx https://github.com/docker/buildx/releases/download/latest/buildx.linux-amd64

Thanks

[crazy-max]

Not a good practice to blindly consume the latest release imo. What if there is a breaking change in a major release or unattended changes that you would not expect?

Anyway you can do something like this:

$ wget -O /usr/lib/docker/cli-plugins/docker-buildx https://github.com/docker/buildx/releases/download/latest/buildx-$(curl --silent "https://api.github.com/repos/docker/buildx/releases/latest" | jq -r '.tag_name').linux-amd64

Also if we remove version from artifact name, we also need to update all downstream repos/references that currently include the version in the filename to download the binary. So I'm not really ok doing it. WDYT @tonistiigi @thaJeztah?

[driverpt]

We are always installing the latest version of both Docker and Buildx when generating the Machine Image. We're already using a script similar to that one.

If we have any issues, then we will change the Recipe and specify a version until the latest gets fixed.

To prevent issues in filename renaming, i suggest you put both in Github releases during a transition period, WDYT ?

[thaJeztah]

Hm... yeah, so effectively they already have a unique URL (per release), and would be installed without the version, so from that perspective (for binary releases), it makes sense to not include the version in the download itself. Looks like there's no "common" convention though, e.g.;

• containerd includes version; https://github.com/containerd/containerd/releases/tag/v1.6.4
• compose does not https://github.com/docker/compose/releases/tag/v2.5.0
• runc does not https://github.com/opencontainers/runc/releases/tag/v1.1.2

For the https://download.docker.com/linux/static/stable/x86_64/ packages, it'd be somewhat different, as all of those will be in the same directory, so a version would be needed there.

And yeah, migrating from one to the other may be an issue

also /cc @tianon

[tianon]

Representing just one downstream, I don't have any problem with a rename here (I'll just adjust to match :+1:), but I know it's extremely unlikely that I'm the only one embedding these URLs. :innocent:

[tianon]

(I don't think a "transition release" with both really helps much though -- most affected users won't necessarily even notice the duplication and so it'll just delay the adjustment they make to the next release instead.)

[n1ngu]

Not a good practice to blindly consume the latest release imo. What if there is a breaking change in a major release or unattended changes that you would not expect?

@crazy-max But that's our option. It is a downstream problem if they are not properly testing their builds or can't afford to repair breaking changes caused by an aggressive updating policy.

If someone wants to pin the artifact they can do so without the releases/latest/download/ARTIFACT url and use the good-old releases/download/VERSION/ARTIFACT

If I am bound to parse the API output as you suggested, I'd expect to extract the browser_download_url from the released artifacts instead. But again this is not easily done (compared to e.g. docker-compose) because the name of the artifact is changed in every release due to this very same issue.