docs: Add a release process guide

This guide serves to illustrate import aspects of patchworks release
process: when, why and how. It also serves as a helpful reminder for
the maintainers themselves.

Signed-off-by: Stephen Finucane <stephen.finucane@intel.com>

1 files changed, 32 insertions, 0 deletions

diff --git a/docs/releasing.md b/docs/releasing.md
new file mode 100644
index 0000000..d8e005d
--- /dev/null
+++ b/docs/releasing.md
@@ -0,0 +1,32 @@
+# Release Process
+
+## Versioning
+
+Since version 1.0, patchwork has implemented a version of
+[Semantic Versioning][ref-semver]. To summarise, releases take the format
+**MAJOR.MINOR.PATCH** (or just **MAJOR.MINOR**). We increment:
+
+1. **MAJOR** version when we make major UI changes or functionality updates
+2. **MINOR** version when we make minor UI changes or functionality updates
+3. **PATCH** version when we make make bug fixes, dependency updates etc.
+
+In Git, each release will have a tag indicating the version number. In
+addition, each release series has it's own branch called `stable/MAJOR.MINOR`
+to allow backporting of bugfixes or security updates to older versions.
+
+## Release Cycle
+
+There is no cadence for releases: they are made available as necessary.
+
+## Supported Versions
+
+Typically all development should occur on `master`. While we will backport
+bugfixes and security updates, we will not backport any new features. This
+is to ensure stability for users of these versions of patchwork.
+
+## Release Checklist
+
+* Documentation has been updated with latest release version
+* Documentation references latest supported version of Django
+
+[ref-semver]: http://semver.org/
\ No newline at end of file