Add documentation for release process

src/en/SUMMARY.md

@@ -28,4 +28,5 @@
   - [Local Development](contributing/local_development.md)
   - [Tests](contributing/tests.md)
   - [Federation Development](contributing/federation_development.md)
+  - [Release Process](contributing/release_process.md)
 - [Code of Conduct](code_of_conduct.md)

src/en/contributing/release_process.md

@@ -0,0 +1,20 @@
+Branching and Releases
+===
+
+## Branches
+
+In general, our handling of branches is the one described in [A stable mainline branching model for Git](https://www.bitsnbites.eu/a-stable-mainline-branching-model-for-git/). One difference is that we avoid rebase, and instead merge the base branch into the current working branch. This helps to avoid force pushes and conflicts.
+
+## Releases
+
+- For major release: make a new branch `release/v0.x`
+- For minor release: cherry-pick desired changes onto `release/v0.x` branch
+- Make a beta or release candidate version with `docker/prod/deploy.sh`
+- Do the same for `lemmy-ui`: `./deploy.sh 0.x.0-rc-x`
+- Deploy to federation test instances
+    -  keeping one instance at the last stable version to test federation compatibility (automate this with ansible)
+    -  eg: `ansible-playbook -i federation playbooks/site.yml --vault-password-file vault_pass -e "override_lemmy_image=dessalines/lemmy:0.x.0-rc.x override_lemmy_ui_image=dessalines/lemmy-ui:0.x.0-rc.x"`
+- Test that everything works as expected, make new beta/rc releases if needed
+- Deploy to lemmy.ml, to discover remaining problems
+- If that went well, make the official `0.x.0` release with `docker/prod/deploy.sh`
+- Announce the release on Lemmy, Matrix, Mastodon