For preparing the release a manuel workflow should be available that takes care of the common preparation. But this can also be done manually if so desired. The workflow does:
- upgrade the version according to the targeted release (
major,minor,patch)majorandminorrequire all crates to be updatedpatchinstead only upgrades the crates that had any changes
- updates the changelog according to Keep-A-Changelog convention
- commits and pushes the changes to remote
After everything is prepared for the new version. A new release can be created from the ui. The tag will not be available as it isn't set by the prepare workflow, so a new tag needs to be created.
The tag and name of the release should be named like v<version> where version is the version of the binary to be
published. As release notes, copy the entries from the changelog for this release.
The release should be created as draft, which will trigger the workflow that will publish the changed crates and binary. The workflow will:
- check if all crates needs to be published or only certain crates
- publish the crates in a specific order while excluding crates that didn't have any changes
- publish the binary
After the workflow was successful the version can be published.
Publishing librespot to crates.io is a slightly convoluted affair due to the various dependencies that each package has on other local packages. The order of publishing that has been found to work is as follows:
protocol -> core -> audio -> metadata -> playback -> connect -> librespot
The protocol package needs to be published with cargo publish --no-verify due to the build script modifying the
source during compile time. Publishing can be done using the command cargo publish in each of the directories of the
respective crate.