Add release instructions to README

README.md

@@ -4,29 +4,26 @@
 
 ## Overview
 
-This repository is the home of application code used by NPG to manage data and 
+This repository is the home of application code used by NPG to manage data and
 metadata in WSI [iRODS](https://irods.org).
 
 It includes:
 
 - iRODS CLI utilities
-  - Metadata verification and repair.
-  - Checksum verification and repair.
-  - Replica verification and repair.
-  - Safe bulk copy.
-  - Safe bulk deletion.
+    - Metadata verification and repair.
+    - Checksum verification and repair.
+    - Replica verification and repair.
+    - Safe bulk copy.
+    - Safe bulk deletion.
 
 - General purpose API
-  - Managing standard WSI iRODS metadata.
+    - Managing standard WSI iRODS metadata.
 
 - Analysis platform-specific API and CLI utilities
-  - Managing Oxford Nanopore metadata and permissions.
-
+    - Managing Oxford Nanopore metadata and permissions.
 
 ## Installing
 
-See [Building and testing](#building-and-testing).
-
 The easiest way to get the CLI scripts is to use the pre-built Docker image (the image
 includes the necessary iRODS clients):
 
@@ -38,9 +35,11 @@ docker pull ghcr.io/wtsi-npg/npg-irods-python:latest
 docker pull ghcr.io/wtsi-npg/npg-irods-python:1.1.0
 ```
 
-## Running tests
+## Building and testing
 
-### Running directly on your local machine
+### Running tests
+
+#### Running directly on your local machine
 
 To run the tests locally, you will need to have the `irods` clients installed (`icommands`
 and `baton`, which means your local machine must be either be running Linux, or have
@@ -53,7 +52,7 @@ With this in place, you can run the tests with the following command:
 
     pytest --it
 
-### Running in a container
+#### Running in a container
 
 The tests can be run in a container, which requires less setup and will be less likely
 to be affected by your local environment. A Docker Compose file is provided to run the
@@ -70,6 +69,18 @@ To pre-build the image, you can run:
 
     docker-compose build
 
+## Creating a release
+
+Releases are created automatically by GitHub Actions when a new tag is pushed to the
+master branch. In a local clone of the repository:
+
+1. Run `git checkout devel ` to check out the `devel` branch
+2. Run `git pull` to update the `devel` branch
+3. Run `git checkout master` to check out the `master` branch
+4. Run `git merge devel ` to merge the `devel` branch into the `master` branch
+5. Run `git tag -a X.Y.Z -m X.Y.Z` to create a new tag
+6. Push the branch and tag with `git push --tags origin master`
+
 ## Logging
 
 ### Structured logging
@@ -83,10 +94,10 @@ unstructured messages.
 
 This package uses the standard Python logging library to deliver log messages. When a
 script has the option `--log-config`, the user can specify a configuration file
-to modify logging behaviour e.g. to set log levels and add new log destinations. 
+to modify logging behaviour e.g. to set log levels and add new log destinations.
 
-The configuration file must be JSON, in the form of a standard logging [configuration 
-dictionary](https://docs.python.org/3/library/logging.config.html#configuration-dictionary-schema). 
+The configuration file must be JSON, in the form of a standard logging [configuration
+dictionary](https://docs.python.org/3/library/logging.config.html#configuration-dictionary-schema).
 
 An example configuration is provided in the file `logging.json`:
 
@@ -126,7 +137,6 @@ An example configuration is provided in the file `logging.json`:
 }
 ```
 
-
 In the `stderr` handler, the `level` option refers to the starting priority to consider.
 Its priority of INFO means that it will log all messages to STDERR starting from INFO,
 including WARNING, ERROR and FATAL. Whereas the `syslog` handler will log ERROR and