multiple PRs
diff --git a/documents/process/release.md b/documents/process/release.md index c948c52..4d58fe4 100644 --- a/documents/process/release.md +++ b/documents/process/release.md
@@ -104,8 +104,9 @@ * Try to include a bump to the crate version (so that future patch releases know they are starting on a newer version) * If possible, avoid mixing functional changes with generated files (e.g. data or FFI) in the commit that lands on the main branch. * If your release also requires uplifting patches to a utils crate (and other crates not versioned with ICU4X), update their `Cargo.toml`s on `main` to reflect the version you wish to publish, to simplify things for people making ICU4X major/minor releases in the future. In this case, try to avoid publishing the util from `main`: it's fine if there have already been out-of-cycle util releases on `main`, but if this is the first util release since the last ICU4X release, cherry pick just the necessary changes onto the release branch. -* Check out the `release/x.y` branch. On this branch: +* Check out the `release/x.y` branch and make a PR. On this branch: * Cherry-pick the functional change from the main branch + * If doing multiple cherry-picks, please use one PR per cherry-pick. * Cherry-pick the changelog update if it was a separate commit * Regenerate code / data if necessary * Make a commit updating the version number of the component if necessary (this should have already been done in the commit cherry-picked from main, but it's not always possible) @@ -115,8 +116,7 @@ * Perform the release. It is crucial that the commit that `cargo publish` was run from is available in the `release/x.y` branch, as Cargo includes that commit in the published crate and it is useful for supply-chain security and tracking. * Perform `cargo publish --dry-run` to catch *many* (but not all) of the reasons a publish may fail. * In particular, if the patch release contains multiple crates, dry run publishes will often not succeed. - * Merge the PR into `release/x.y` - * In case the PR contains multiple cherry-picks and you wish them to be tracked separately, you may temporarily allow merge commits and ensure the PR merges as a fast-forward merge. You may also simply do this as multiple PRs, one per uplift. + * Merge the PR(s) into `release/x.y` * Update `release/x.y` locally and check it out * Run `cargo publish` in the crate(s) * *If* `cargo publish` fails, make a new PR to fix the release branch and get it merged with review. You may admin-merge minor fixes that are mostly tweaking versions in Cargo.toml.