Publishing Documentation Via Read The Docs

This page is about publishing the documentation i.e. making changes or new releases visible to the public.  For information on updating the source 'text' see the Getting Started Writing Documentation Guide

To try to avoid too much confusion we will refer to releases and branches when talking about the documentation source, and versions when talking about published documentation.
We will refer to the Read The Docs service as RTD.

The RTD uses the branches and tags to link versions of the documentation to moments in time in the source, to update the tags and branches seen by RTD, run a build of master

Producing/updating documentation for a specific 'release/branch' is different depending on whether the version is liked to a tag or branch. (it's not consistent - sorry about that it was like that when I found it).

If the versions of documentation are linked to tags (ie release notes) then you need to:

1. Checkout that branch of documentation and tag the latest (assuming you want the very latest) commit with the version i.e. 4.11.1.0
2. Update the available tags in RTD by running a build of master.
3. Then create a version linked to the tag that you added previously
4. Then build that version.

The reading of tags is dynamic, so you can remove and re-add a tag and then rebuild that 'version'.

If the versions of documentation are linked to branches (ie Installation Docs) then *TO DO not sure if this bit is true yet* create a branch using the version as the name of the branch.

merging a pull request into that branch will cause the version to be built and updated online automatically

When proofing a new version of documentation, you can set the version to 'protected' this stops the version from being browseable or from appearing to users in menus, but it is directly accessible.