Latest version of a static binary - naming consideration
basil (Basil Hendroff) September 6, 2020, 6:04pm #1
Extract for the Caddy V2 documentation…
screenshot.540990×527 26.6 KB
This suggests that the download root is https://github.com/caddyserver/caddy/releases/latest/download with the ASSET choices listed under https://github.com/caddyserver/caddy/releases. For example, the FreeBSD (x64) version of the static binary is named caddy_2.1.1_freebsd_amd64.tar.gz
The naming convention used for the asset doesn't lend itself to scripting the download of the latest version because the version number is included in the asset name. When, say, 2.2.0 of a static binary is released, the script would have to be modified to point to the new asset. From a scripting perspective, it would be helpful if the asset name for the latest version were independent of the version number e.g. caddy_freebsd_amd64.tar.gz. When the script is run, it would acquire the latest version whatever that might be at the time.
matt (Matt Holt) September 7, 2020, 5:12am #2
All true… and I thought of this too, but in the past we saw a lot of requests for the version number to be included in the filename so that it was easy to identify which version was downloaded without having to run the program (or remember which version it was at the time of the download), especially since it is often downloaded on a different platform so running it isn't always possible/convenient.
basil (Basil Hendroff) September 8, 2020, 2:36am #3
Selfishly, and I understand that there's considerable effort involved initially and ongoing, and I understand that it would probably only benefit the few of us that script, and I'll drop it after this post, but I wonder if both audiences could be catered for? (I'm being somewhat cheeky here.)
I think as a workaround, some people are using a GitHub API call to get the latest tag or release or something like that.
basil:
Selfishly, and I understand that there's considerable effort involved initially and ongoing, and I understand that it would probably only benefit the few of us that script, and I'll drop it after this post, but I wonder if both audiences could be catered for?
Maybe; what do you suggest, exactly?
Considering the graphic in my previous post, and acknowledging that this is just wishful thinking…
Those of us who are quite happy to enter caddy version to determine the version of Caddy would download caddy_freebsd_amd64.tar.gz from the latest path shown in the graphic.
Those of us who would prefer to see the version in the filename e.g. caddy_2.2.0_freebsd_amd64.tar.gz would download from one of the other paths shown in the graphic.
The workaround I use atm is to build Caddy from source within the script. This avoids the version issue, but of course this takes time.
matt (Matt Holt) September 8, 2020, 12:15pm #7
I don't know if we can customize the file paths; GitHub chooses those for us. All we have control over are the filename and its contents.
Note that this is only possible if you're downloading for the same platform you're currently using. Often people download to deploy onto a different platform so they can't run the binary to get the version.
basil (Basil Hendroff) September 8, 2020, 12:14pm #8
Hi Matt, I understand now there's a GitHub limitation. I appreciate you taking the time to explore the idea with me. Fortunately, due to the stability of Caddy, there aren't frequent releases so it isn't such a big issue to change a script pointer to a newer version of the asset.
system (system) closed December 5, 2020, 6:04pm #9
This topic was automatically closed after 90 days. New replies are no longer allowed.