Merge branch 'mnt/external' into 'external'

Mnt/external

See merge request fsl/conda/manifest!17

README.md

@@ -4,15 +4,15 @@
 This repository is used to manage FSL releases. The `fsl-release.yml` file
 defines the packages that are installed as part of a FSL release.
 
-
 FSL release `manifest.json` and `environment.yml` files are automatically
 generated from information stored in this repository, using CI rules and
 scripts in the fsl/conda/manifest-rules> repository.
 
 
 This repository contains two branches:
- - Public and development FSL releases are created from the `master` branch
- - Internal FSL releases are created from the `internal` branch
+ - Public FSL releases are created from tags on the `external` branch.
+ - Development releases are created from commits on the `external` branch.
+ - Internal FSL releases are created from the `master` branch
 
 
 ## The `fslinstaller.py` script
@@ -83,9 +83,9 @@ channels:
  - conda-forge
  - defaults
 
-# Private internal channel for development and
-# testing releases. This is prepended to the
-# channels list for development releases.
+# Private channel containing packages that are
+# only released internally. This is prepended
+# to the channels list for internal releases.
 internal_channel: http://${FSLCONDA_USERNAME}:${FSLCONDA_PASSWORD}@18.133.213.73/internal/
 
 # List of FSL conda packages and their
@@ -111,16 +111,17 @@ Note that there are two types of manifest file:
     may be re-generated on new public releases, and on updates to e.g. the
     fslinstaller script.
 
-  - Development manifests, containing information about one
-    internal/development FSL release. Development manifests are generated for
-    every internal release. Development manifests are named according to a
-    standard convention described in the **Internal/development FSL releases**
-    section, below.
+  - Development manifests, containing information about one internal or
+    development FSL release. Development manifests are generated for every
+    internal or development release. Development manifests are named according
+    to a standard convention described in the **Internal/development FSL
+    releases** section, below.
 
 
 Manifest and environment files can only be published when they are generated
 from a new tag, or when they are generated from specific branches (currently
-`master` or `internal`).
+`master` or `external`). However, manifest and environment files can be
+downloaded as GitLab artifacts from any branch.
 
 
 ## New FSL releases
@@ -134,9 +135,9 @@ _Summary:_
    the new release.
 
 
-New public FSL releases are denoted by adding a tag to this repository. The
-tag is used as the FSL version identifier, which must be of the form
-`X.Y.Z[.W]`, where X, Y, Z, and W are integers.
+New public FSL releases are denoted by adding a tag to the `external` branch
+of this repository. The tag is used as the FSL version identifier, which must
+be of the form `X.Y.Z[.W]`, where X, Y, Z, and W are integers.
 
 When a new tag is added to this repository, the `manifest.json` and
 `environment.yml` files are generated from the contents of `fsl-release.yml`,
@@ -164,16 +165,16 @@ web interface, via the `deploy-environment-files` and
 
 
 _Summary:_
- - New internal FSL release are created by adding commits to the `internal`
+ - New internal FSL release may be created by adding commits to the `master`
    branch of this repository
- - New development releases can be created by adding commits to the `master`
+ - New development releases may be created by adding commits to the `external`
    branch of this repository
  - In both cases, the `deploy-environment-files` and
    `deploy-development-manifest` jobs on the associated CI pipelines must be
    started manually.
 
 
-When commits are added to the `master` or `internal` branch of this
+When commits are added to the `master` or `external` branch of this
 repository, separate `manifest.json` and `environment.yml` files are generated
 from the contents of `fsl-release.yml` and made available for download.  These
 files are assigned a version identifier of the form
@@ -211,7 +212,7 @@ via the `deploy-environment-files` and `deploy-development-manifest` jobs.
 
 _Summary:_
  - The public release `manifest.json` file can be updated by adding commits to
-   the `master` branch of this repository
+   the `master` or `external` branches of this repository
  - The `deploy-release-manifest` job on the associated CI pipeline must be
    started manually.
 
@@ -226,11 +227,11 @@ Normally, `manifest.json` files that are not associated with a tag are named
 `manifest-<tag>.<date>.<commit>.<branch>.json` as outlined above. However, a
 new release `manifest.json` file is always re-generated, and can be deployed
 through the Gitlab web interface, via the `deploy-release-manifest` job (with
-the caveat that only files generated from the `master` or `internal` branches
+the caveat that only files generated from the `master` or `external` branches
 may be published).
 
 
 Release `manifest.json` files which are generated from branches will only
 contain information about past official FSL releases. Release `manifest.json`
-files which are generated from tags will contain information about past
+files which are generated from new tags will contain information about past
 official FSL release, and also about the new FSL release.

fsl-release.yml

@@ -6,7 +6,7 @@
 release_url: http://18.133.213.73/releases/
 
 # Latest fslinstaller version
-installer: 1.0.14
+installer: 1.0.15
 
 # URLs to miniconda installers to
 # use for all supported platforms
@@ -136,7 +136,7 @@ packages:
  - fsl-ptx2-cuda-10.2 2101.1
  - fsl-ptx2-cuda-11.0 2101.1
  - fsl-ptx2-cuda-9.2 2101.1
- - fsl-pyfeeds 0.9.7
+ - fsl-pyfeeds 0.9.8
  - fsl-pyfeeds-tests 2106.0
  - fsl-qboot 2010.0
  - fsl-randomise 2101.0