CI: Add a release preparation and release workflow

[photovoltex]

I think this is in a reviewable state now, where we can discuss over the details.

The idea behind the release flow is described in PUBLISHING.md. But broken down, there is a manual workflow that takes care of the manual preparation steps and a automatic workflow that is triggered when a github release is created (only created because we want to create a draft and only publish when the workflow is done).

Maybe we could also use this already for 0.7.1, then we would see how only some crates are updated as only playback, connect and core changed so far.

Disclaimer:

• what is missing for this to work:
  • we need to at a secret to the repository for crates.io access
• what I couldn't test so far:
  • commit and pushing in the preparation workflow
  • the publish itself in the release workflow, but as dry-run it seems to work well

[roderickvd]

Ooohh, from Rust 1.90.0 release:

Cargo adds native support for workspace publishing

cargo publish --workspace is now supported, automatically publishing all of the crates in a workspace in the right order (following any dependencies between them).

This has long been possible with external tooling or manual ordering of individual publishes, but this brings the functionality into Cargo itself.

Native integration allows Cargo's publish verification to run a build across the full set of to-be-published crates as if they were published, including during dry-runs. Note that publishes are still not atomic -- network errors or server-side failures can still lead to a partially published workspace.

[photovoltex]

I'm currently adjusting the release workflow to use that new info. How does that interact with crates that generate code and need --no-verify as flag, like protocol? Does that mean you have to use --no-verify for the entire workspace then?

[Copilot]

Pull Request Overview

This PR replaces the existing manual shell script publishing workflow with an automated GitHub Actions-based release process. The new system separates release preparation from the actual publishing, providing better control and automation.

Key changes:

• Removes the old publish.sh script and replaces it with GitHub Actions workflows
• Transitions from workspace-based versioning to individual crate versioning for 0.7.1
• Introduces a two-step release process: preparation via manual workflow, then publishing via release creation

Reviewed Changes

Copilot reviewed 17 out of 17 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
publish.sh	Removes the legacy bash publishing script
*/Cargo.toml	Updates all crates to use explicit version "0.7.1" instead of workspace version
PUBLISHING.md	Updates documentation to describe the new GitHub Actions-based release workflow
.github/workflows/release.yml	Adds automated workflow for publishing crates when a GitHub release is created
.github/workflows/prepare-release.yml	Adds manual workflow for preparing releases with version bumping and changelog updates
.github/workflows/build.yml	Removes publish.sh from ignored paths since it no longer exists
.github/scripts/bump-versions.sh	Adds script for intelligent version bumping based on changed crates
.github/example/prepare-release.event	Adds example event file for testing the prepare-release workflow
CHANGELOG.md	Minor formatting fix to use angle bracket URL format

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[photovoltex]

I tested the workspace publishing with a dry-run for a patch version and that seemed to work quite well. So I adjusted the release workflow to use that, as it reduces a lot of unnecessary complexity

[roderickvd]

What's the current state? You think we could try next release with it? 🤞
(not now but when we're ready for a new release)

Edit: asking because I saw more than a few review comments as not resolved yet.

[photovoltex]

I think I did go over every comment of yours and changed/adjusted the code or added a comment to it explaining why I would like it to be as is.

[kingosticks]

I can look over this tomorrow eve, if that's helpful.

[photovoltex]

@roderickvd @kingosticks Anything that requires doing on this PR? Otherwise we could use this for the next minor version release then?

[roderickvd]

Would be great to give it the shot! Next release should be v0.8.0 no? Because of the various breaking changes to the API.

[photovoltex]

Yeah, 0.8 would be the next version. I just now resolved all open discussion. The next version will be interesting as the protocol will be updated too and we don't provide the no-verify flag (see the quote comment from the old script). So this flow might still be faulty, but I didn't wanted to invoke the entire publish with the no-verify flag.

Protocol crate needs --no-verify option due to build.rs modification.

[photovoltex]

To use the workflow we still need to add a secret to the repository named CARGO_REGISTRY_TOKEN with a token from crates.io, so that it can publish automated. @roderickvd I think you are the only one who has access to the account currently, could you take care of that?

When that is done, I would merge this PR and see how good it works for 0.8 if no one has a problem with that?

[roderickvd]

OK, I've added an CARGO_REGISTRY_TOKEN repository secret with publish-update and yank authorization on the librespot crate. By all means give it a try and release v0.8.0!

[photovoltex]

So first issue encountered. The action can't automatically commit on dev and it states a PR is required. Will see what the best solution is. ctx: https://github.com/librespot-org/librespot/actions/runs/19214559117/job/54921880838

[photovoltex]

I added the maintain role to the ruleset, which can now bypass the restriction on all branches. That should probably be fine?

[photovoltex]

Hmm, those ruleset settings are quite annoying. Even tho I added myself via a group to a bypass list, it doesn't bypass the ruleset... And I don't want to disable the PR required rule as it seems quite important to have.