DOC: Describe staging version convention

development_workflow.md

@@ -83,6 +83,9 @@ example, two versions of a core FSL project released in the month of January
 2021 would be assigned versions `2021.0` and `2021.1`.
 
 
+> See also the section below on development/staging releases.
+
+
 ## FSL conda package naming conventions
 
 
@@ -152,3 +155,60 @@ repository is updated, and a new conda package built and released.
 For projects which are included in FSL, but developed externally
 (e.g. [MSM](https://github.com/ecr05/MSM_HOCR)), the recipe repository is
 manually updated on an as-needed basis.
+
+
+## Development (a.k.a. *staging*) releases
+
+
+FSL projects are released as conda packages, and therefore need to adhere to
+conda package versioning conventions, described at
+https://docs.conda.io/projects/conda/en/latest/user-guide/concepts/pkg-specs.html#version-ordering.
+
+
+Conda packages for all FSL projects are published to two conda channels:
+
+ - The *production* channel, which contains conda packages built from the most
+   recently tagged version of each FSL project.
+ - The *staging* channel, which contains conda packages built from the most
+   recent state of the `master` branch on the project git repository.
+
+
+The production channel is used for official FSL installations, and for releasing
+important changes and bug fixes to end users. The staging channel is used for
+internal releases.
+
+Every time a new tag is added to a project repository, a *production* package
+is built and uploaded to the production channel. Every time new commits are
+added to the master branch of a project repository, a *staging* package is
+built and uploaded to the staging channel.
+
+
+Packages published to the production channel are versioned as described above
+in the **FSL project versioning scheme** section. Packages published to the
+staging channel are versioned slightly differently, to ensure a sensible
+ordering of version numbers across both staging and production packages. The
+version string for a staging package adheres to the following structure:
+
+
+    <last_production_tag>.post0.dev<date>[+<commit>]
+
+
+where:
+
+ - `<last_production_tag>` is the version/tag for the most recent production
+   release
+ - `<date>` is the date (`YYYYMMDD`) that the staging package was built
+ - `<commit>` is the first 7 characters of the git commit that the staging
+   package was built from.
+
+
+For exmaple, if the latest production release for the `fsl/base` project is
+`2106.1`, and a new commit, with hash `ac28d14`, is subsequently pushed to
+the `fsl/base` master branch on 8 June 2021, the resulting staging package
+will be assigned the version string `2106.1.post0.dev20210608+ac28d14`.
+
+
+This convention ensures that, when an environment is created with the staging
+channel having higher priority than the production channel, staging packages
+which are built after the most recent production package will be given higher
+priority, and will be installed in preference to the production package.