Update release branch name in dev docs

dev-docs/source/GitWorkflow.rst

@@ -85,7 +85,7 @@ When creating a pull request you should:
 
   - The title should **not** contain the issue number
 - `Reference the issue which the pull request is closing  <https://github.com/blog/1506-closing-issues-via-pull-requests>`_, using one of `these <https://help.github.com/articles/closing-issues-via-commit-messages>`_ keywords
-- State the user and facility (if relevant) who initiated the original issue, if they are named in the issue. Please do not put full email addresses on the Pull Request, as it is publicly accessible. 
+- State the user and facility (if relevant) who initiated the original issue, if they are named in the issue. Please do not put full email addresses on the Pull Request, as it is publicly accessible.
   If the user would not be easily identified by someone picking up the ticket, be prepared to act as a point of contact with the reporter.
 - Ensure the description follows the format described by the `PR
   template
@@ -128,8 +128,7 @@ Code Freeze
 ^^^^^^^^^^^
 
 At the start of a *code freeze* before a major release there will be a
-release branch created with the name ``release-vX.Y``, where ``X.Y``
-are the major and minor version numbers, respectively. At this point
+release branch created named ``release-next``. At this point
 only bugfixes should be applied to this release branch so that it can
 be stabilized for the release. The release branch will be merged to
 ``master`` periodically so bugfixes do not need to be separately
@@ -143,7 +142,7 @@ created from the correct base branch depending on the scope of the
 changes:
 
 - ``master``: maintenance fixes, new features. Command: ``git fetch -p && git checkout --no-track -b MYBRANCH_NAME origin/master``
-- ``release-vX.Y``: bugfixes. Command: ``git fetch -p && git checkout --no-track -b MYBRANCH_NAME origin/release-X.Y``
+- ``release-next``: bugfixes. Command: ``git fetch -p && git checkout --no-track -b MYBRANCH_NAME origin/release-next``
 
 Pull Requests
 -------------

dev-docs/source/JenkinsConfiguration.rst

@@ -357,7 +357,7 @@ Update Branches For Jobs
     import hudson.plugins.git.BranchSpec
     import static com.google.common.collect.Lists.newArrayList;
 
-    def NEW_BRANCH = "*/release-v3.8"
+    def NEW_BRANCH = "*/release-next"
 
     // Access to the Hudson Singleton
     def jenkins = jenkins.model.Jenkins.instance;

dev-docs/source/PatchReleaseChecklist.rst

@@ -33,9 +33,9 @@ Authorisation
 Development
 ###########
 
-The patch release will be prepared based off the branch used to
-construct to most recent major point release, e.g. ``release-v3.9``
-would be used for any ``3.9.x`` patches. Changes for the patch should be made using the standard GitHub
+The patch release will be prepared based off the tag used to mark
+the last minor release. A branch called ``release-next`` will be created from this tag.
+Changes for the patch should be made using the standard GitHub
 workflow for merging code with ``master``. The issue and pull request should then have the ``PatchCandidate`` label applied to them. These
 commits will then be cherry picked from ``master`` on to the release branch.
 
@@ -47,8 +47,7 @@ version of the last major/patch release. It is not a requirement but
 advised to unfix the patch number while the patch is being compiled.
 This prevents the nightly builds from generating a collection of packages that have
 exactly the same version. The patch number can be unfixed by commenting the line in
-https://www.github.com/mantidproject/mantid/blob/release-vX.Y/buildconfig/CMake/VersionNumber.cmake#L9, where
-``X.Y`` should be replace with the appropriate numbers.
+https://www.github.com/mantidproject/mantid/blob/release-next/buildconfig/CMake/VersionNumber.cmake#L9.
 
 Release Notes
 -------------
@@ -107,11 +106,9 @@ On the day of release a few steps are required:
 
 * update the patch version:
 * navigate to
-  https://www.github.com/mantidproject/mantid/blob/release-X.Y./buildconfig/CMake/VersionNumber.cmake,
-  where ``X`` & ``Y`` are the major and minor release versions
-  respectively.
+  https://www.github.com/mantidproject/mantid/blob/release-next/buildconfig/CMake/VersionNumber.cmake
 * edit the ``VERSION_PATCH`` to the required number for the patch and
-  commit the result.
+  commit the result
 * run a manual build of all of the OS jobs under {{
   site.mantidreleasebuilds }} and when asked for a suffix use an empty
   string

dev-docs/source/ReleaseChecklist.rst

@@ -137,10 +137,10 @@ Once the unscripted testing has passed:
 * Disable release deploy jobs by executing
   `close-release-testing <http://builds.mantidproject.org/view/All/job/close-release-testing>`__
   job.
-* On the ``release-vX.Y`` branch, update major & minor versions
+* On the ``release-next`` branch, update major & minor versions
   accordingly in ``buildconfig/CMake/VersionNumber.cmake``. Also
   uncomment ``VERSION_PATCH`` and set it to ``0``.
-* Merge ``release`` branch back to ``master``
+* Merge ``release-next`` branch back to ``master``
 * Comment out patch number on ``master`` branch
 * Draft a `new
   release <https://github.com/mantidproject/mantid/releases>`__ on