Open RokeJulianLockhart opened 12 months ago
Do you have example of project proposing this kind of release page ? thanks
IMHO this is not a good idea: It does not solve the winget problem because the manifest includes the hash.
Besides, this can be implemented by removing versions from filenames, then release/latest
link will work (e.g. https://github.com/uutils/coreutils/releases/latest/download/coreutils_0.0.23_arm64.deb ).
https://github.com/uutils/coreutils/issues/5542#issuecomment-1812839663
@sylvestre,
There's also some useful discussion and positive reception to the issue at:
Right, lots of things to consider here I think. Let's hope I get what this is about: if I understand correctly, you want an easy way to download artifacts for the main
branch? Or do you want the release/latest
thing mentioned above?
First, let's consider the current state:
We could add a page to the website with the latest artifacts or something like that? How would you propose we implement this?
@tertsdiepraam,
We could add a page to the website with the latest artifacts or something like that? How would you propose we implement this?
Probably how https://github.com/ClementTsang/bottom/releases/ does — https://github.com/ClementTsang/bottom/releases/tag/nightly.
Is that generated every day? What does that provide to you over the normal releases?
https://github.com/uutils/coreutils/issues/5542#issuecomment-1813442092
No, @tertsdiepraam, I don't want to it to be generated each day, though I don't particularly care if it works (nightly builds obviously probably wouldn't though). I'm providing an example of an unversioned release which is updated at regular intervals, as you requested. All that you would need to do differently is change it to use the same release schedule as the others, perhaps by copying the binaries generated for the last versioned release into the unversioned one.
Alright, I understand now! Thanks! So, the release/latest
link is not enough?
https://github.com/uutils/coreutils/issues/5542#issuecomment-1813448087
I... wasn't aware that existed, @tertsdiepraam. In a bout of intense shame, I pass the baton of whether to reopen this issue onto you the participants here. There might yet be rationale for having a dedicated latest release like https://github.com/ClementTsang/bottom/releases/tag/nightly does, but I can't imagine it being more useful than https://github.com/uutils/coreutils/releases/latest. Ah, gee.
https://github.com/uutils/coreutils/issues/5542#issuecomment-1813451760
Aha! I just found the rationale whilst testing furiously, attempting to regain my lost honour:
Although https://github.com/uutils/coreutils/releases/latest is useful for a human, linking to specific assets is unsupported even when the URI correlates to the version that the asset's filename includes. For instance, https://github.com/uutils/coreutils/releases/latest/coreutils-0.0.23-x86_64-pc-windows-msvc.zip returns 404. Additionally, because the assets are currently versioned too in their filenames, vanity filenames would be necessary in the unversioned release too.
Oh yeah that makes sense :)
For instance, uutils/coreutils/releases/latest/coreutils-0.0.23-x86_64-pc-windows-msvc.zip returns 404.
Linking to specific assets is supported. It's 404 Not Found because /download
is missing — https://github.com/uutils/coreutils/releases/latest/download/coreutils-0.0.23-x86_64-pc-windows-msvc.zip returns 302 Found and redirects to https://github.com/uutils/coreutils/releases/download/0.0.23/coreutils-0.0.23-x86_64-pc-windows-msvc.zip . (Your conclusion still holds, however)
It shall allow programs that use GitHub as their ultimate origin point for binaries to not worry about versions, instead always pulling the latest version. Not everything supports RegEx. For example, https://github.com/uutils/coreutils/issues/4291#issuecomment-1812814643.