Add cargo-binstall support and adopt Rust target triple naming

[Muktarsadiq]

Summary

This PR adds support for cargo-binstall and transitions release assets to use Rust's standard target triple naming convention.

Changes

• Updated .github/workflows/cd.yml:

  • Added target triple mapping for release assets
  • Generates both new (Rust target triple) and legacy naming formats for backwards compatibility
  • Updated release notes to document the naming change

• Updated Cargo.toml:

  • Added package.metadata.binstall configuration pointing to the full variant

• Updated installation documentation:

  • Added cargo-binstall as the recommended installation method
  • Updated asset naming examples to use new format
  • Clarified architecture-specific download instructions

Migration Plan

• This release (0.4.2): Both naming formats available
• Next release: Remove legacy naming format

Testing

Users will be able to install spotifyd with:

cargo binstall spotifyd

Testing Note

Full end-to-end testing of cargo-binstall functionality requires a release with the new asset naming format. The workflow changes have been validated for syntax and logic, but actual installation testing will be possible after the first release with these changes.

I'm happy to help verify the installation works once a test release is created.

Closes #1200

[eladyn]

Thanks for the contribution! I added some minor comments. Once everything looks good, I'll give this a try on my fork. :)

On another note: Some of your changes seem a little AI-like, so I wanted to kindly ask you to disclose this and the extent to which this is true, if this is indeed the case. I realize that we currently don't have any contribution guidelines regarding AI usage, but I - just speaking for myself - would like to give this some thought before just accepting AI-generated contributions. If this is just false accusations, I'm very sorry in advance, and please don't take that as an offense!

[eladyn]

Wouldn't it be possible to just use rustc -vV to automatically determine the host target triple?

[Muktarsadiq]

You're absolutely right, using rustc -vV is cleaner and more reliable. I'll make that change. Thanks for the suggestion.

[eladyn]

I think, I'd rather not have cargo-binstall be the recommended installation method. Official packages by distributions will probably have better compatibility with the user's system and don't require a working rust / cargo installation...

[Muktarsadiq]

Yeah that makes sense, I’ll remove the “Recommended” wording and position cargo-binstall as an optional convenience method for users who already have Rust/Cargo installed

[eladyn]

I'm not entirely sure, but I think the code above will remove -legacy before publishing the release. And probably, if we want to keep a legacy version, this should keep the identical naming as previously.

[Muktarsadiq]

Yes you’re right, the packaging step removes the -legacy suffix, so legacy artifacts would not retain their original naming and this could lead to confusion or potential naming conflicts. I can remove the artifact_name=${artifact_name%-legacy line so legacy releases keep the -legacy suffix and preserve the previous naming format. Does that approach work for you?

[eladyn]

This is rather picky, but maybe we can keep the previous formatting of the Cargo.toml file. :)

[Muktarsadiq]

No problem at all, I'll revert to the original formatting. Consistency is important.

[eladyn]

I don't think we provide Windows binaries currently, what does this do?

[Muktarsadiq]

You're right, you don't currently provide Windows binaries, this is premature optimisation. I added it based on cargo-binstall's support matrix (https://github.com/cargo-bins/cargo-binstall/blob/main/SUPPORT.md), but I'm happy to remove it for now. We can add it back when/if Windows builds are introduced.

[eladyn]

As the current version is 0.4.2, this should probably be 0.4.3. (And before we forget to remove it later on, maybe we can just omit this part or at least the one about the legacy naming, what do you think?)

[Muktarsadiq]

That makes sense, since this is a one time transition, the version specific documentation and legacy naming section will become outdated quickly. I'll remove those parts to keep the docs cleaner and avoid future maintenance burden. Thanks for thinking ahead on this!

[Muktarsadiq]

Thanks for the contribution! I added some minor comments. Once everything looks good, I'll give this a try on my fork. :)

On another note: Some of your changes seem a little AI-like, so I wanted to kindly ask you to disclose this and the extent to which this is true, if this is indeed the case. I realize that we currently don't have any contribution guidelines regarding AI usage, but I - just speaking for myself - would like to give this some thought before just accepting AI-generated contributions. If this is just false accusations, I'm very sorry in advance, and please don't take that as an offense!

Thanks for the contribution! I added some minor comments. Once everything looks good, I'll give this a try on my fork. :)

On another note: Some of your changes seem a little AI-like, so I wanted to kindly ask you to disclose this and the extent to which this is true, if this is indeed the case. I realize that we currently don't have any contribution guidelines regarding AI usage, but I - just speaking for myself - would like to give this some thought before just accepting AI-generated contributions. If this is just false accusations, I'm very sorry in advance, and please don't take that as an offense!

My apologies, yes, I used AI (Claude) to help refine the YAML changes and improve the README documentation. Specifically, it helped with:

• Writing clearer release notes explaining the naming change
• Adding the deprecation warning

I should have disclosed this upfront. Going forward, I'll be more transparent about AI assistance and ensure all contributions align with the project's guidelines.