|
2 | 2 |
|
3 | 3 | ## How To |
4 | 4 |
|
5 | | -Read through this paragraph in its entirety before running anything. |
| 5 | +1. [prepare the release](#prepare-the-release) |
| 6 | +2. [create a github-release](#creating-a-github-release) |
6 | 7 |
|
7 | | -The Bash script in the root of the project, named `publish.sh` can be used to publish a new version of librespot and its corresponding crates. the command should be used as follows from the project root: `./publish 0.1.0` from the project root, substituting the new version number that you wish to publish. *Note the lack of a v prefix on the version number. This is important, do not add one.* The v prefix is added where appropriate by the script. |
| 8 | +### Prepare the release |
8 | 9 |
|
9 | | -Make sure that you are are starting from a clean working directory for both `dev` and `master`, completely up to date with remote and all local changes either committed and pushed or stashed. |
| 10 | +For preparing the release a manuel workflow should be available that takes care of the common preparation. But |
| 11 | +this can also be done manually if so desired. The workflow does: |
| 12 | +- upgrade the version according to the targeted release (`major`, `minor`, `patch`) |
| 13 | + - `major` and `minor` require all crates to be updated |
| 14 | + - `patch` instead only upgrades the crates that had any changes |
| 15 | +- updates the changelog according to Keep-A-Changelog convention |
| 16 | +- commits and pushes the changes to remote |
10 | 17 |
|
11 | | -Note that the script will update the crates and lockfile, so in case you did not do so before, you really should to make sure none of the dependencies introduce some SemVer breaking change. Then commit so you again have a clean working directory. |
| 18 | +### Creating a github-release |
12 | 19 |
|
13 | | -Also don't forget to update `CHANGELOG.md` with the version number, release date, and at the bottom the comparison links. |
| 20 | +After everything is prepared for the new version. A [new release can be created](https://github.com/librespot-org/librespot/releases/new) |
| 21 | +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. |
| 22 | +The tag should be named like `v<version>` where `version` is the version of the binary. |
14 | 23 |
|
15 | | -You will want to perform a dry run first: `./publish --dry-run 0.1.0`. Please make note of any errors or warnings. In particular, you may need to explicitly inform Git which remote you want to track for the `master` branch like so: `git --track origin/master` (or whatever you have called the `librespot-org` remote `master` branch). |
| 24 | +> insert convention what the release title and release notes should be and what checkboxes to check etc. |
16 | 25 |
|
17 | | -Depending on your system the script may fail to publish the main `librespot` crate after having published all the `librespot-xyz` sub-crates. If so then make sure the working directory is committed and pushed (watch `Cargo.toml`) and then run `cargo publish` manually after `publish.sh` finished. |
| 26 | +The release should be created as draft, which will trigger the workflow that will publish the changed crates and binary. |
| 27 | +The workflow will: |
| 28 | +- check if all crates needs to be published or only certain crates |
| 29 | +- publish the crates in a specific order while excluding crates that didn't have any changes |
| 30 | +- publish the binary |
18 | 31 |
|
19 | | -To publish the crates your GitHub account needs to be authorized on `crates.io` by `librespot-org`. First time you should run `cargo login` and follow the on-screen instructions. |
20 | | - |
21 | | -## What the script does |
22 | | - |
23 | | -This is briefly how the script works: |
24 | | - |
25 | | - - Change to branch master, pull latest version, merge development branch. |
26 | | - - Change to working directory. |
27 | | - - Change version number in all files. |
28 | | - - Update crates and lockfile. |
29 | | - - Commit and tag changes. |
30 | | - - Publish crates in given order. |
31 | | - - Push version commit and tags to master. |
| 32 | +After the workflow was successful the version can be published. |
32 | 33 |
|
33 | 34 | ## Notes |
34 | 35 |
|
35 | | -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 publising that has been found to work is as follows: |
36 | | - |
37 | | -`protocol -> core -> audio -> metadata -> playback -> connect -> librespot` |
38 | | - |
39 | | -The `protocol` package needs to be published with `cargo publish --no-verify` due to the build script modifying the source during compile time. |
40 | | - |
41 | | -Publishing can be done using the command `cargo publish` in each of the directories of the respective crate. |
| 36 | +Publishing librespot to crates.io is a slightly convoluted affair due to the various dependencies that each package has |
| 37 | +on other local packages. The order of publishing that has been found to work is as follows: |
| 38 | +> `protocol -> core -> audio -> metadata -> playback -> connect -> librespot` |
42 | 39 |
|
43 | | -The script is meant to cover the standard publishing process. There are various improvements that could be made, such as adding options such as the user being able to add a changelog, though this is not the main focus, as the script is intended to be run by a CI. Feel free to improve and extend functionality, keeping in mind that it should always be possible for the script to be run in a non-interactive fashion. |
| 40 | +The `protocol` package needs to be published with `cargo publish --no-verify` due to the build script modifying the |
| 41 | +source during compile time. Publishing can be done using the command `cargo publish` in each of the directories of the |
| 42 | +respective crate. |
0 commit comments