Commit 99c4338b authored by Paul McCarthy's avatar Paul McCarthy 🚵
Browse files

DOC: Describe staging version convention

parent 1a86e59f
......@@ -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](, 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
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>` is the version/tag for the most recent production
- `<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.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment