Document release process (#847)

CONTRIBUTING.md

@@ -76,6 +76,74 @@ suggestions invoke it directly:
 vale somefile
 ```
 
+## Creating releases
+
+To keep the release process in line with best practices for open source
+repositories, not all steps are automated. Specifically, tags should be signed
+and pushed manually and the release notes should be human readable beyond what
+most automatically generated changelogs provide.
+
+1. Bump the current version in the following files:
+
+   - `flake.nix`
+   - `MODULE.bazel`
+   - `Cargo.toml`
+   - `nativelink-*/Cargo.toml`
+   - `nativelink-docs/package.json`
+
+2. Run `git cliff --tag=0.x.y > CHANGELOG.md` to update the changelog. You might
+   need to make manual adjustments to `cliff.toml` if `git-cliff` doesn't put a
+   commit in the right subsection.
+
+3. Create the commit and PR. Call it `Release NativeLink v0.x.y`.
+
+4. Once the PR is merged, update your local repository and origin:
+
+   ```bash
+   git switch main
+   git pull -r upstream main
+   git push
+   ```
+
+5. Create a **signed** tag on the release commit and give it the same tag
+   message as the name of the tag. This tag should be the version number with a
+   `v` prefix:
+
+   ```bash
+   git tag -s v0.x.y
+
+   # tag message should be: v0.x.y
+   ```
+
+6. Push the signed tag to the origin repository:
+
+   ```bash
+   git push origin v0.x.y
+   ```
+
+7. Pushing the tag triggers an additional GHA workflow which should create the
+   container images in your own fork. Check that this workflow is functional. If
+   the CI job in your fork passes, push the tag to upstream:
+
+   ```bash
+   git push upstream v0.x.y
+   ```
+
+8. The images for the release are now being created. Go to the [Tags](https://github.com/TraceMachina/nativelink/tags)
+   tab in GitHub and double-check that the tag has a green `Verified` marker
+   next to it. If it does, select `Create a release from tag` and create release
+   notes. You can use previous release notes as template by clicking on the
+   "Edit" button on a previous release and copy-pasting the contents into the
+   new release notes.
+
+   Make sure to include migration instructions for all breaking changes.
+
+   Explicitly list whatever changes you think are worth mentioning as `Major
+   changes`. This is a fairly free-form section that doesn't have any explicit
+   requirements other than being a best-effort summary of notable changes.
+
+9. Once all notes are in line, click `Publish Release`.
+
 ## Conduct
 
 NativeLink Code of Conduct is available in the