Release without version number in file names

[j1elo]

Please, consider using names without version numbers in the files that get published as GitHub Release assets (https://github.com/FiloSottile/mkcert/releases).

GitHub has a very nice feature that converts this URL:

https://github.com/FiloSottile/mkcert/releases/latest/download/${FILENAME}

to this other one:

https://github.com/FiloSottile/mkcert/releases/download/v${LATEST_VERSION}/${FILENAME}

This is very helpful to write instructions (and/or scripts) that will not be anchored to some old version when a user reads it. However, mkcert puts the version number in the release files, so it is not really possible to use the automatic "latest" URL, because the ${FILENAME} is a different one each time.

My proposal is to move to a naming scheme without version numbers:

• mkcert-darwin-amd64
• mkcert-linux-amd64
• mkcert-linux-arm
• mkcert-windows-amd64.exe

This would allow users to grab mkcert from this URL, and be confident that the latest version will always be downloaded, e.g. for Linux:

https://github.com/FiloSottile/mkcert/releases/latest/download/mkcert-linux-amd64

Scripts can already verify the version with two methods: both the redirected download URL, and also with the more standard and ubiquitous --version flag, which mkcert also has.

[rfay]

Just for a different opinion... I'm a big fan of the version number being in the file in releases. It's very easy to script the latest release and create the filename. Having files laying around with no context or versioning is a bad thing.

[j1elo]

Well, my point was that there is already enough ways to know what version is being downloaded, so it is then possible to rename the downloaded file to whatever each user wants. And this also allows to leverage the "latest URL" feature of GitHub.

On the other hand, having the version number in the file is also equally easy to rename and just remove the number from the name, if that's what the user wants... but this loses the "latest URL" feature.

So, given the same practical conditions, one option hinders a useful GitHub feature, and the other does not.

Regardless, the common practice absolutely everywhere in all platforms is to have program names decoupled from program versions, so this shouldn't come as a surprise. I mean that we've never seen commands such as ls-8.25, grep-2.25, etc. on Linux, ping-6.3.9600 on Windows, brew-2.4.0 on Mac, and the same goes for any other platform. This seems to make the most sense, as otherwise all related tooling would need to be updated explicitly every time a new program version is installed.

[goldstar611]

Github has a nice json endpoint at https://api.github.com/repos/FiloSottile/mkcert/releases/latest

combine that with jq and you get something like this to download the latest MacOS amd64 binary:

url=$(curl https://api.github.com/repos/FiloSottile/mkcert/releases/latest | jq -r '.assets[] | select(.browser_download_url | endswith("darwin-amd64")) | .browser_download_url')

Change the endswith() call to what you are interested in.

[j1elo]

Yeah, using jq or other JSON parsers is a good option, albeit it complicates instructions for end users. I just chose to link to the releases page and leave each one to decide which file to download, anyway.

Thanks for reminding me this issue! I think we can close it if there's no intention to change the release naming.