Unexpected change in release asset naming convention (removal of version tag)

[lanius412]

Hi, I noticed that the naming convention for release assets has changed unexpectedly.

Previously, the assets were named: coreutils-{{.Version}}-{{.Arch}}-{{.OS}}.{{.Format}}

However, the 0.6.0 release, they are now: coreutils-{{.Arch}}-{{.OS}}.{{.Format}}

Impact

This change has broken automated installation scripts that rely on the version string being present in the filename.
e.g. aqua, mise

Request

Could you please clarify if this change was intentional? If possible, I would recommend reverting to the previous naming convention (including {{.Version}}) to maintain backward compatibility and ensure easier version tracking of the downloaded binaries.

[sylvestre]

probably not. @oech3 rings a bell ?

[oech3]

It was requested at #9981

[sylvestre]

we should revert it, i want the version name :)
i disagree with #9981

[oech3]

@500-internal-server-error OK?

[sylvestre]

i thought it was for nightly only

i renamed them by hand.

[oech3]

Do you want to fetch latest stable tag with frozen URL (instead of binary from latest comit)?

Stable tag, not latest commit, e.g., so I can do cd /usr/bin && curl -LO https://github.com/uutils/coreutils/releases/latest/coreutils. Though having builds from latest commit as an option can't hurt.

[oech3]

Hmm... I confirmed that cargo-binstall coreutils fetches 0.5.0 .

[500-internal-server-error]

If anything I thought it would be easier for automated tools that already have the version number since the version number is now in only 1 place instead of 2. My request was for tools that don't: e.g., curl -LO https://github.com/uutils/coreutils/releases/latest/coreutils. I am primarily interested in latest stable, whatever that is, but having nightly is also nice.

Can we keep both versioned and unversioned names then?

[oech3]

Keeping both makes CICD.yml complex.

[500-internal-server-error]

Keeping both makes CICD.yml complex.

Surely copying and stripping the version name from one is not that complex?

[oech3]

I think reproducible container builder should use cargo-binstall with previous URLs.

[oech3]

@sylvestre Are you OK to publishing same binaries 2~3 times for both use cases with different URLs?

[sylvestre]

nope
almost all projects have the version in the file name.
i am sure @500-internal-server-error can workaround this

[oech3]

$ curl -s https://api.github.com/repos/uutils/coreutils/tags | jq -r '[.[] | .name | select(. != "latest-commit")] | .[0]'
0.6.0