Add guide for cherry picking

(cherry picked from commit 7458c65e)

CONTRIBUTING.md

@@ -44,7 +44,9 @@ project. It's a pretty simple process:
    diff and are not quite ready to merge, use the `[WIP]` tag in the title to
    prevent your code from being accidentally merged.
 5. Put a comment in the MR saying that it's ready to be merged.
-6. Respond to any comments in the code review.
+6. If your branch is a minor fix that could appear in the next patch release,
+   then add the `Proposed patch` label to the merge request.
+7. Respond to any comments in the code review.
 
 ## Submission checklist
 - Did you add regression tests (for fixes) or unit tests and/or normal tests for
@@ -155,6 +157,60 @@ stick to the following process:
 - Once feedback received from the branch author (if necessary) and reviewers are
   happy, the branch will be merged.
 
+## Release branches
+Nektar++ releases are versioned in the standard form `x.y.z` where `x` is a
+major release, `y` a minor release and `z` a patch release:
+
+- major releases are extremely infrequent (on the order of every 2-3 years) and
+  denote major changes in functionality and the API;
+- minor releases occur around twice per year and contain new features with minor
+  API changes;
+- patch releases are targeted on rougly a monthly basis and are intended to 
+
+The repository contains a number of _release branches_ named `release/x.y` for
+each minor release, which are intended to contain **fixes and very minor
+changes** from `master` and which form the next patch release. This allows us to
+use `master` for the next minor release, whilst still having key fixes in patch
+releases.
+
+### Cherry-picking process
+
+Any branches that are marked with the `Proposed patch` label should follow the
+following additional steps to cherry pick commits into the `release/x.y` branch.
+
+1. If the branch is on a remote other than `nektar/nektar`, make sure that's
+   added to your local repository.
+2. On a local terminal, run `git fetch --all` to pull the latest changes. It's
+   important for the commands below that you do this _before_ you merge the
+   branch into `master`.
+3. Merge the branch into master as usual using GitLab.
+4. Switch to the appropriate branch with `git checkout release/x.y` and update
+   with `git pull`.
+5. Now check the list of commits to cherry-pick.
+
+   ```bash
+   git log --oneline --no-merges --reverse origin/master..REMOTE/fix/BRANCHNAME
+   ```
+
+   where `REMOTE` is the remote on which the branch lives and `BRANCHNAME` is
+   the fix branch. If the list is empty, you probably did a `git fetch` after
+   you merged the branch into `master`; in this case use `origin/master^`.
+6. If you're happy with the list (compare to the MR list on the GitLab MR if
+   necessary), cherry-pick the commits with the command:
+
+   ```bash
+   git cherry-pick -x $(git rev-list --no-merges --reverse origin/master..REMOTE/fix/BRANCHNAME)
+   ```
+
+7. It's likely you'll encounter some conflicts, particularly with the
+   `CHANGELOG`. To fix these:
+   - `git status` to see what's broken
+   - Fix appropriately
+   - `git commit -a` to commit your fix
+   - `git cherry-pick --continue`
+8. If everything becomes horribly broken, `git cherry-pick --abort`.
+9. Once you're happy, `git push` to send your changes back to GitLab.
+
 ## Formatting guidelines
 Nektar++ uses C++, a language notorious for being easy to make obtuse and
 difficult to follow code. To hopefully alleviate this problem, there are a