Merge branch 'doc/readme' into 'internal'

DOC: summaries for public/internal/development releases and manifest updates [skip-ci]

See merge request fsl/conda/manifest!14

README.md

@@ -9,6 +9,11 @@ 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
+
+
 ## The `fslinstaller.py` script
 
 
@@ -120,6 +125,14 @@ from a new tag, or when they are generated from specific branches (currently
 ## New FSL releases
 
 
+_Summary:_
+ - New public FSL release are created by adding a tag to the `master` branch
+   of this repository
+ - The `deploy-release-manifest` and `deploy-environment-files` jobs, on the
+   CI pipeline for the new tag, must be manually started in order to publish
+   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.
@@ -138,19 +151,32 @@ conventions:
     (e.g. `fsl-6.1.0_linux-64_cuda11.0.yml`).
 
 
-After they have been generated, the manifest and environment files are
-published to the FSL release web server.  This publishing step must be manually
-triggered through the GitLab web interface, via the `deploy-environment-files`
-and `deploy-release-manifest` jobs.
+After they have been generated, a test installation of the new release on each
+supported platform is performed using the `fslinstaller.py` script, and then
+the manifest and environment files are published to the FSL release web
+server.  This publishing step must be manually triggered through the GitLab
+web interface, via the `deploy-environment-files` and
+`deploy-release-manifest` jobs.
 
 
 ## Internal/development FSL releases
 
 
-When commits are added to _any_ 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 `<tag>.<date>.<commit>.<branch>`, where:
+_Summary:_
+ - New internal FSL release are created by adding commits to the `internal`
+   branch of this repository
+ - New development releases can be created by adding commits to the `master`
+   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
+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
+`<tag>.<date>.<commit>.<branch>`, where:
 
 
 where:
@@ -182,6 +208,13 @@ via the `deploy-environment-files` and `deploy-development-manifest` jobs.
 ## Updates to `manifest.json`
 
 
+_Summary:_
+ - The public release `manifest.json` file can be updated by adding commits to
+   the `master` branch of this repository
+ - The `deploy-release-manifest` job on the associated CI pipeline must be
+   started manually.
+
+
 Sometimes the contents of the official release `manifest.json` file may need
 to be changed independently of a public FSL release - for example, a new
 version of the `fslinstaller.py` script may be released, or the `miniconda`