Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use static release asset names #168

Open
rhtenhove opened this issue Dec 25, 2023 · 2 comments
Open

Use static release asset names #168

rhtenhove opened this issue Dec 25, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@rhtenhove
Copy link

When wanting to download the latest and greatest release, the GitHub docs show a built-in way to achieve this.

However for this to work, the assets need to have the same name in every release. Then the following example URL would always download the latest x86_64 linux release:

https://github.com/wilsonzlin/minify-html/releases/latest/download/minhtml-x86_64-unknown-linux-gnu

However, since the assets are also versioned, only the following will work now, but break on the next release:

https://github.com/wilsonzlin/minify-html/releases/latest/download/minhtml-0.15.0-x86_64-unknown-linux-gnu

So my request is to name the assets the same every time.

Thanks!

@wilsonzlin
Copy link
Owner

wilsonzlin commented Dec 25, 2023

Thanks for raising, this sounds like a good idea. The only downside I see is that the "default" downloaded name will no longer have the version in it, which has some benefits. I haven't seen this pattern used a lot in other packages though, like ripgrep, bat, and (funnily) GitHub's CLI shown in the linked docs; I wonder why.

One thing to note is that users should do this at their own risk, given there could be breaking changes between releases. (Ideally they should fetch a pinned version e.g. /releases/v0.16.0.)

@wilsonzlin wilsonzlin added the enhancement New feature or request label Dec 25, 2023
@rhtenhove
Copy link
Author

That downside could indeed be a bummer, however that seems only to be the case if you're running multiple versions manually from the same folder (or something similar...).

The latest release link will redirect to the permalink, which contains the version number in the path, which could be extracted from there if so desired. So the information is not lost.

Pinning is indeed preferred, however that is best combined with semantic versioning, so only major version changes introduce breakages. This would need some release mechanism which would allow for for example ^v1.0.0 which would refer to the latest in v1.x.x, so perhaps something for the future. First to get to that first stable release 😎

Pinning can of course still happen if the enhancement described above is introduced.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants