github-mirrors/librespot
1
0
Fork 0
mirror of https://github.com/librespot-org/librespot.git synced 2024-11-08 16:45:43 +00:00
Code Issues Projects Releases Packages Wiki Activity

Document crate and changelog updates

Browse source
This commit is contained in:
Roderick van Domburg 2022-08-01 23:14:21 +02:00 committed by GitHub
parent 2bce489159
commit 8ffaf7cb8d
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 8 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
PUBLISHING.md
View file

@ -8,19 +8,24 @@ The Bash script in the root of the project, named `publish.sh` can be used to pu
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. 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.
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.
Also don't forget to update `CHANGELOG.md` with the version number, release date, and at the bottom the comparison links.
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). 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).
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. 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.
To publish the crates your GitHub account needs to be authorized on `crates.io` by `librespot-org`. 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.
## What the script does ## What the script does
This is briefly how the script works: This is briefly how the script works:
- Change to branch master, pull latest version, merge development branch. - Change to branch master, pull latest version, merge development branch.
- CD to working dir. - Change to working directory.
- Change version number in all files. - Change version number in all files.
- Update crates and lockfile.
- Commit and tag changes. - Commit and tag changes.
- Publish crates in given order. - Publish crates in given order.
- Push version commit and tags to master. - Push version commit and tags to master.
@ -35,4 +40,4 @@ The `protocol` package needs to be published with `cargo publish --no-verify` du
Publishing can be done using the command `cargo publish` in each of the directories of the respective crate. Publishing can be done using the command `cargo publish` in each of the directories of the respective crate.
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 change log, 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. 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.