1
1
# Publishing new versions of uefi-rs to Crates.io
2
2
3
- This guide documents the best practices for publishing new versions of
4
- the crates in this repository to [ crates.io] ( https://crates.io/ ) .
3
+ This guide documents how to publish new versions of the crates in this
4
+ repository to [ crates.io] ( https://crates.io/ ) .
5
5
6
6
** It is mostly intended for maintainers of the uefi-rs project.**
7
7
8
- ## Bumping the crate versions
8
+ ## Overview
9
+
10
+ 1 . Create a branch that updates the versions of all packages you want to
11
+ release. This branch should include all related changes such as updating the
12
+ versions in dependent crates and updating the changelog.
13
+ 2 . Create a PR of that branch. The subject of the PR must start with ` release: ` ,
14
+ the rest of the message is arbitrary.
15
+ 3 . Once the PR is approved and merged, a Github Actions workflow will take care
16
+ of creating git tags and publishing to crates.io.
17
+
18
+ ## Details of the release pull request
9
19
10
20
For ensuring compatibility within the crates ecosystem,
11
21
Cargo [ recommends] [ cargo-semver ] maintainers to follow the [ semantic versioning] [ semver ] guidelines.
@@ -15,58 +25,46 @@ which crates were modified and how should their version numbers be incremented.
15
25
16
26
Incrementing the version number of a crate is as simple as editing
17
27
the corresponding ` Cargo.toml ` file and updating the ` version = ... ` line,
18
- then committing the change (preferably on a new branch, so that all the version bumps
19
- can be combined in a single pull request).
28
+ then committing the change.
20
29
21
30
### Crate dependencies
22
31
23
32
The dependency graph of the published crates in this repo is:
24
33
25
- - ` uefi-services ` depends on ` uefi ` (the root project)
26
- - ` uefi ` depends on ` uefi-macros `
27
-
28
- If there are breaking changes happening in the project, we should first publish
29
- a new version of ` uefi-macros ` , then of ` uefi ` , then of ` uefi-services ` and so on.
30
-
31
- For example, if the signature of a widely-used macro from ` uefi-macros ` is changed,
32
- a new major version of that crate will have to be published, then a new version of
33
- ` uefi ` (major if the previous bump caused changes in the public API of this crate as well),
34
- then possibly a new version of ` uefi-services ` .
34
+ - ` uefi-services ` depends on ` uefi `
35
+ - ` uefi ` depends on ` uefi-macros ` and ` uefi-raw `
35
36
36
37
### Updating the dependent crates
37
38
38
39
Remember that if a new major version of a crate gets released, when bumping the version
39
40
of it's dependents you will have to also change the dependency line for it.
40
41
41
- For example, if ` uefi-macros ` gets bumped from ` 1.1 .0` to ` 2.0 .0` ,
42
+ For example, if ` uefi-macros ` gets bumped from ` 0.5 .0` to ` 0.6 .0` ,
42
43
you will also have to update the corresponding ` Cargo.toml ` of ` uefi ` to be:
43
44
44
45
``` toml
45
- uefi-macros = " 2.0 .0"
46
+ uefi-macros = " 0.6 .0"
46
47
```
47
48
48
- The dependencies in ` template/Cargo.toml ` should also be updated to the new version.
49
+ The dependencies in ` template/Cargo.toml ` and ` book/src/tutorial/app.md ` should
50
+ also be updated to the new version.
49
51
50
52
[ cargo-semver ] : https://doc.rust-lang.org/cargo/reference/semver.html
51
53
[ semver ] : https://semver.org/
52
54
53
- ## Publishing new versions of the crates
55
+ ### Updating the changelog
54
56
55
- This section is mostly a summary of the official [ guide to publishing on crates.io] [ cargo-publishing-reference ] ,
56
- with a few remarks regarding the specific of this project.
57
-
58
- Start by following the steps in the guide. When running ` cargo publish ` ,
59
- you will have to use a custom ` --target ` flag to be able to build/verify the crates:
60
-
61
- ```
62
- cargo publish --target x86_64-unknown-uefi
63
- ```
57
+ Update the [ ` CHANGELOG.md ` ] ( CHANGELOG.md ) file in order to move all the
58
+ unpublished changes to their respective version, and prepare it for tracking
59
+ further changes. The date of the release should be included next to the section
60
+ title as done for the other releases.
64
61
65
- [ cargo-publishing-reference ] : https://doc.rust-lang.org/cargo/reference/publishing.html
62
+ ## Crates.io secret token
66
63
67
- ## Updating the changelog
64
+ The release.yml workflow expects a repository secret named
65
+ ` CARGO_REGISTRY_TOKEN ` . This is set in the [ repository settings] [ secret ] . The
66
+ value must be a crates.io [ API token] . The scope of the token should be
67
+ restricted to ` publish-update ` .
68
68
69
- After bumping the crate versions, we should also update the [ ` CHANGELOG.md ` ] ( CHANGELOG.md ) file
70
- in order to move all the unpublished changes to their respective version, and prepare it for
71
- tracking further changes. The date of the release should be included next to the section title as
72
- done for the other releases.
69
+ [ secret ] : https://github.com/rust-osdev/uefi-rs/settings/secrets/actions
70
+ [ API token ] : https://crates.io/settings/tokens
0 commit comments