docs: document the new release process and possible improvements

CONTRIBUTING.md

@@ -76,11 +76,7 @@ Once the release is prepared, it'll go through a review:
 2. Make sure that we're correctly following semver.
 3. Make sure that we're not missing anything in the changelogs.
 
-Finally, an [FVM "owner"](https://github.com/orgs/filecoin-project/teams/fvm-crate-owners/members) will:
-
-1. Merge the release PR to master (this will trigger GitHub release/tag creation if the workspace version in the root `Cargo.toml` was modified).
-2. For each released crate, create a git tag: `crate_name@crate_version`.
-3. Run `cargo publish` for each released crate (in dependency order).
+Finally, an [FVM "owner"](https://github.com/orgs/filecoin-project/teams/fvm-crate-owners/members) will follow the [release process](#release-process).
 
 ### Crate Dependency Graph
 
@@ -112,3 +108,45 @@ If that works, proceed with releasing these crates.
 [chat]: https://docs.filecoin.io/about-filecoin/chat-and-discussion-forums/#chat
 [discuss]: https://github.com/filecoin-project/fvm-specs/discussions
 [issue]: https://github.com/filecoin-project/ref-fvm/issues
+
+### Release Process
+
+This section describes the automated parts of the release process and the manual steps FVM owners need to take.
+
+#### Current State
+
+1. On a release pull request creation, a [Release Checker](.github/workflows/release-check.yml) workflow will run. It will perform the following actions:
+    1. Extract the version from the modified `Cargo.toml` files. Process each crate in the workspace **independently**.
+    2. Check if a git tag for the version, using the `crate_name@version` as the pattern, already exists. Continue only if it does not.
+    3. Create a draft GitHub release with the version as the tag.
+    4. Comment on the pull request with a link to the draft release.
+    5. Run `cargo publish --dry-run` for the crate for which the release is proposed.
+2. On pull request merge, a [Releaser](.github/workflows/release.yml) workflow will run. It will perform the following actions:
+    1. Extract the version from the modified `Cargo.toml` files. Process each crate in the workspace **independently**.
+    2. Check if a git tag for the version, using the `crate_name@version` as the pattern, already exists. Continue only if it does not.
+    3. Check if a draft GitHub release with the version as the tag exists.
+    4. If the draft release exists, publish it. Otherwise, create a new release with the version as the tag.
+3. **[MANUAL]** Run `cargo publish` for each crate that has been released in the [reverse dependency order](#crate-dependency-graph).
+
+#### Known Limitations
+
+1. `cargo publish --dry-run` will fail if a crate has a dependency on a crate that has not been published yet (i.e. that is being published in the same release).
+2. `cargo publish` has to be run manually.
+
+#### Possible Improvements
+
+1. Run `cargo publish --dry-run` in the [reverse dependency order](#crate-dependency-graph). Use a local registry to simulate the dependencies that are not yet published.
+2. Run `cargo publish` in the [**reverse dependency order**](#crate-dependency-graph) automatically after the merge.
+
+<details>
+<summary>How to?</summary>
+
+1. Figure out which crates need to be published.
+2. Either determine the correct order, or hard-code it in a config.
+3. Run `cargo vendor --versioned-dirs`, creating a `.cargo/config.toml` file to respect the vendor directory.
+4. In publish order (reverse dependency order):
+    1. Run `cargo package`.
+    2. Copy the package (the extracted one) out of `target/packages` into `vendor`.
+    3. Generate the `.cargo-checksum.json` file for that manually vendored package. This is the most annoying step, but shouldn't be hard with `find` + `jq`...
+
+</details>