Standardise release asset filenames

[daniporr]

Description of the new feature

Including version numbers in release assets, as is currently the case (e.g., Microsoft.WindowsTerminal_1.24.10921.0_x64.zip) makes it difficult to provide a unique link for downloading the latest version via a script, where you could use a link such as the following: https://github.com/microsoft/terminal/releases/latest/download/Microsoft.WindowsTerminal.zip.
However, if the version number is included in the filename, as shown above, this method will not work.

Moreover, including the version number in the assets is unnecessary, as releases already contain the version number, via the respective tag.

Proposed technical implementation details

Just remove the version numbers from the released assets.

[DHowett]

Thanks for the request!

However: I'm sorry, but no. Much better-regarded projects than we here use version numbers in their release archives.

standardise

unique link

Considering that we have been doing this for seven years and that we are in the heady company of e.g. curl, I would argue that it is a standard. It also provides the most uniqueness we possibly can provide.

unnecessary

Well, I dunno...

There are things that we feel are rather more important than vanity URLs. 🙂

[DHowett]

As a footnote: we have seen the pain that comes from folks submitting version-less "evergreen" URLs to package repositories like WinGet and buildroot/openwrt/yocto/any of the other Linux distribution construction kits. They all store the hash of the last known version, and then builds or installs fail because the archive has moved on faster than the distributor is aware of.

I would not want to afford even the chance of that happening with Terminal, because I don't want to deal with the incoming bug reports that tell me that "you changed the package but not the URL."

[daniporr]

Thank you, I appreciate your quick and direct answer.

Much better-regarded projects than we here use version numbers in their release archives.

I am unsure whether the claim that "others are doing the same" constitutes a valid argument for such a choice. Perhaps they were using a different release system where including version numbers in names was essential to differentiate between various versions, and they simply maintained the same pipeline when they moved to GitHub, or perhaps they never even considered it.

Nevertheless, I appreciate the references to other projects that would benefit from the same change; I may try to suggest the same idea to them.

Considering that we have been doing this for seven years and that we are in the heady company of e.g. curl, I would argue that it is a standard. It also provides the most uniqueness we possibly can provide.

Perhaps "standardise" has been misinterpreted; I meant that the name should remain the same across all releases, which is the opposite of providing "the most uniqueness".

Well, I dunno...
...
There are things that we feel are rather more important than vanity URLs. 🙂

This can only happen if you download the same asset from different releases. I am unsure when this might occur, but if you need to do so, you can simply save them with different names. You would have downloaded them from different URLs, each of which includes the version number, making this easy to achieve even programmatically.

As a footnote: we have seen the pain that comes from folks submitting version-less "evergreen" URLs to package repositories like WinGet and buildroot/openwrt/yocto/any of the other Linux distribution construction kits. They all store the hash of the last known version, and then builds or installs fail because the archive has moved on faster than the distributor is aware of.

I never suggested having version-less URLs in package repositories like WinGet; I only discussed assets on GitHub.