Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 15 additions & 2 deletions src/for-maintainers/release-process.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,20 @@ The version bump should be merged **after** this commit, so that all changes men

Create a branch with the name `release/vX.Y.Z`, based on the commit that bumped the version number (in `main`).
If the date of merge was (significantly) later, and significant changes were made, then the release branch can also be based on an earlier commit and the version number bump backported / re-applied.
The branch should be pushed to the upstream servo repository.
The branch should be pushed to the upstream servo repository.

### Request a stylo release

In order to publish `servo` to crates.io we need a stylo release, corresponding to the git commit we depend on.
Check the stylo commit hash specified in servos Cargo.toml, and open an issue on stylo requesting a release based on that commit.
Usually the stylo release is handled by @Loirooriol.
Once the new stylo release has been published, we need to create a PR against the servo release branch to update stylo to the crates.io version.
Create a branch based on the release branch, and edit the `Cargo.toml` to depend on the released crates, like in this [servo stylo bump example].
Note that not all crates share the same stylo workspace version number, so pure search and replace won't work.
The `servo` PR against the release branch will be merged with `rebase`, so be sure to squash your commits if you have more than one.

[stylo]: https://github.com/servo/stylo
[servo stylo bump example]: https://github.com/servo/servo/commit/77fccacc1f1fdce10498d50173aafaa09d02879e

### Creating a draft release for testing

Expand Down Expand Up @@ -52,4 +65,4 @@ Contact the dedicated signer of the macOS artifact and ask them to sign the rele
This might take a while, so this should be done a couple of days before the planned release date.

Finally, add our usual release notes summary, linking to the blog post and to the common issues section (check the previous release notes for examples).
Once the blog post is published, we publish the release.
Once the blog post is published, we publish the release.