RFC Branches, Channels, and Tags

README.md

@@ -327,6 +327,11 @@ Run the benchmarks:
 $ cargo +nightly bench --features="unstable"
 ```
 
+Release Process
+---
+The release process for this project is described [here](rfcs/rfc-005-branches-tags-and-channels.md).
+
+
 Code coverage
 ---
 

rfcs/rfc-005-branches-tags-and-channels.md

@@ -0,0 +1,59 @@
+```
+========================= master branch (edge channel) =======================>
+         \                      \                     \
+          \___v0.7.0 tag         \                     \
+           \                      \         v0.9.0 tag__\
+            \          v0.8.0 tag__\                     \
+ v0.7.1 tag__\                      \                 v0.9 branch (beta channel)
+              \___v0.7.2 tag         \___v0.8.1 tag
+               \                      \
+                \                      \
+           v0.7 branch         v0.8 branch (stable channel)
+
+```
+
+## Branches and Tags
+
+### master branch
+All new development occurs on the `master` branch.
+
+Bug fixes that affect a `vX.Y` branch are first made on `master`.  This is to
+allow a fix some soak time on `master` before it is applied to one or more
+stabilization branches.
+
+Merging to `master` first also helps ensure that fixes applied to one release
+are present for future releases.  (Sometimes the joy of landing a critical
+release blocker in a branch causes you to forget to propagate back to
+`master`!)"
+
+Once the bug fix lands on `master` it is cherry-picked into the `vX.Y` branch
+and potentially the `vX.Y-1` branch.  The exception to this rule is when a bug
+fix for `vX.Y` doesn't apply to `master` or `vX.Y-1`.
+
+Immediately after a new stabilization branch is forged, the `Cargo.toml` minor
+version (*Y*) in the `master` branch is incremented by the release engineer.
+Incrementing the major version of the `master` branch is outside the scope of
+this document.
+
+### v*X.Y* stabilization branches
+These are stabilization branches for a given milestone.  They are created off
+the `master` branch as late as possible prior to the milestone release.
+
+### v*X.Y.Z* release tag
+The release tags are created as desired by the owner of the given stabilization
+branch, and cause that *X.Y.Z* release to be shipped to https://crates.io,
+https://snapcraft.io/, and elsewhere.
+
+Immediately after a new v*X.Y.Z* branch tag has been created, the `Cargo.toml`
+patch version number (*Z*) of the stabilization branch is incremented by the
+release engineer.
+
+## Channels
+Channels are used by end-users (humans and bots) to consume the branches
+described in the previous section, so they may automatically update to the most
+recent version matching their desired stability.
+
+There are three release channels that map to branches as follows:
+* edge - tracks the `master` branch, least stable.
+* beta - tracks the largest (and latest) `vX.Y` stabilization branch, more stable.
+* stable - tracks the second largest `vX.Y` stabilization branch, most stable.