@@ -24,7 +24,7 @@ Our release process is as follows:
24
24
4 . Bump the versions of all crates to the new version in their Cargo.toml and in
25
25
the root ` Cargo.toml ` as well, and push these changes to the release PR.
26
26
- If you released a new version of ` ibc-derive ` in step 3, make sure to
27
- update that dependency.
27
+ update that dependency.
28
28
- Verify that there is no dev-dependency among the workspace crates. This is
29
29
important, as ` cargo-release ` ignores dev-dependency edges. You may use
30
30
` cargo-depgraph ` :
@@ -38,41 +38,60 @@ Our release process is as follows:
38
38
because of release order complicacy (except maybe inside ` ibc-testkit` , as
39
39
it is the top crate that depends on ` ibc` crate and no other crate depends
40
40
on it).
41
- - In order to resolve such a situation, the dev dependencies other than ` ibc-testkit`
42
- can be manually released to crates.io first so that the subsequent crates that
43
- depend on them can then be released via the release process. For instructions
44
- on how to release a crate on crates.io, refer [here](https://doc.rust-lang.org/cargo/reference/publishing.html).
45
- 5. Run ` cargo doc -p ibc --all-features --open` locally to double-check that all
41
+ - In order to resolve such a situation, the dev dependencies other than
42
+ ` ibc-testkit` can be manually released to crates.io first so that the
43
+ subsequent crates that depend on them can then be released via the release
44
+ process. For instructions on how to release a crate on crates.io, refer
45
+ [here](https://doc.rust-lang.org/cargo/reference/publishing.html).
46
+ 5. Beware of [crates-io rate limit][cargo-release-rate-limit]. It is 5 for
47
+ publishing new crates and 30 for publishing existing crates. But the number
48
+ of our crates has reached 31. So we publish a leaf crate, ` ibc-primitives`
49
+ manually and release the rest of the 30 crates via CI.
50
+ - Release ` ibc-primitives` by running:
51
+ ` ` ` sh
52
+ cargo release -p ibc-primitives --no-push --no-tag --allow-branch main --execute
53
+ ` ` `
54
+ - Validate the number of crates that need to be released via CI, it can not
55
+ be more than 30.
56
+ - There should be a 10 minutes delay between the release of ` ibc-primitives`
57
+ and the release of the rest of the crates on CI.
58
+ - If new crates are added, we need to recompute the set of crates that we
59
+ want to release via CI. The rest must be released manually.
60
+ 6. Run ` cargo doc -p ibc --all-features --open` locally to double-check that all
46
61
the documentation compiles and seems up-to-date and coherent. Fix any
47
62
potential issues here and push them to the release PR.
48
- 6 . Mark the PR as ** Ready for Review** and incorporate feedback on the release.
63
+ 7 . Mark the PR as ** Ready for Review** and incorporate feedback on the release.
49
64
Once approved, merge the PR.
50
- 7. Checkout the ` main` and pull it with ` git checkout main && git pull origin main` .
51
- 8. Create a signed tag ` git tag -s -a vX.Y.Z` . In the tag message, write the
65
+ 8. Checkout the ` main` and pull it with
66
+ ` git checkout main && git pull origin main` .
67
+ 9. Create a signed tag ` git tag -s -a vX.Y.Z` . In the tag message, write the
52
68
version and the link to the corresponding section of the changelog. Then push
53
69
the tag to GitHub with ` git push origin vX.Y.Z` .
54
70
- The [release workflow][release.yaml] will run the ` cargo release --execute`
55
- command in a CI worker.
56
- 9 . If some crates have not been released, check the cause of the failure and
57
- act accordingly:
71
+ command in a CI worker.
72
+ 10 . If some crates have not been released, check the cause of the failure and
73
+ act accordingly:
58
74
1. In case of intermittent problems with the registry, try ` cargo release`
59
- locally to publish any missing crates from this release. This step
60
- requires the appropriate privileges to push crates to [crates.io].
75
+ locally to publish any missing crates from this release. This step
76
+ requires the appropriate privileges to push crates to [crates.io].
61
77
2. If there is any new crate published locally, add
62
- [ibcbot](https://crates.io/users/ibcbot) to its owners list.
63
- 3. In case problems arise from the source files, fix them, bump a new
64
- patch version (e.g. ` v0.48.1` ) and repeat the process with its
65
- corresponding new tag.
66
- 10 . Once the tag is pushed, wait for the CI bot to create a GitHub release,
67
- then update the release description and append:
68
- ` [📖CHANGELOG](https://github.com/cosmos/ibc-rs/blob/main/CHANGELOG.md#vXYZ)`
78
+ [ibcbot](https://crates.io/users/ibcbot) to its owners list.
79
+ 3. In case problems arise from the source files, fix them, bump a new patch
80
+ version (e.g. ` v0.48.1` ) and repeat the process with its corresponding
81
+ new tag.
82
+ 11 . Once the tag is pushed, wait for the CI bot to create a GitHub release, then
83
+ update the release description and append:
84
+ ` [📖CHANGELOG](https://github.com/cosmos/ibc-rs/blob/main/CHANGELOG.md#vXYZ)`
69
85
70
86
# ## Communications (non-technical) release pipeline
71
87
72
- - Notify the communications team about the pending release and prepare an announcement.
73
- - Coordinate with other organizations that are active in IBC development (e.g., Interchain) and keep them in the loop.
88
+ - Notify the communications team about the pending release and prepare an
89
+ announcement.
90
+ - Coordinate with other organizations that are active in IBC development (e.g.,
91
+ Interchain) and keep them in the loop.
74
92
75
93
All done! 🎉
76
94
77
95
[crates.io]: https://crates.io
78
96
[release.yaml]: https://github.com/cosmos/ibc-rs/blob/main/.github/workflows/release.yaml
97
+ [cargo-release-rate-limit]: https://github.com/crate-ci/cargo-release/blob/4b09269/src/steps/mod.rs#L214-L268
0 commit comments