Skip to content

Commit

Permalink
Post merge fixes (#11530)
Browse files Browse the repository at this point in the history
* Fix indent

* Tweak link and fix text
  • Loading branch information
plaindocs authored Aug 8, 2024
1 parent c2f1819 commit 1bc451b
Showing 1 changed file with 5 additions and 3 deletions.
8 changes: 5 additions & 3 deletions docs/user/versions.rst
Original file line number Diff line number Diff line change
Expand Up @@ -40,7 +40,7 @@ You can change the states for each version of your documentation in the :guilabe
- You have a work in progress version and don't want to publish its docs just yet.

Hidden verions are listed as ``Disallow: /path/to/version/``
in the default `robots.txt file <https://www.robotstxt.org/>`__ created by Read the Docs.
in the default :doc:`/reference/robots` created by Read the Docs.

**Public** or **Private** (only available on on :doc:`/commercial/index`)
- Public versions are visible to everyone.
Expand All @@ -51,6 +51,7 @@ You can change the states for each version of your documentation in the :guilabe
In addition, if you want other users to view the build page of your public versions,
you'll need to the set the :doc:`privacy level of your project </commercial/privacy-level>` to public.


Tags and branches
-----------------

Expand Down Expand Up @@ -104,13 +105,14 @@ all of which can be reconfigured if necessary:
set the **Default Branch** to the branch you use.

- **tags** are semantic versioning compatible (according to `PEP 440`_) snapshots
of your documentation. The most recent semantic tag maps to the ``stable`` tag.
of your documentation. The most recent semantic tag maps to the ``stable`` version.

Semantic versioning allows "normal" version numbers like ``1.4.2``, as
well as pre-releases like this: ``2.0a1``. The ``stable`` version of your documentation never includes a pre-release.

- If you have documentation changes on a **long-lived branch**,
you can build those too, to see how the new docs will be built.
This is most useful for **release branches**, which are maintained over time for a specific release. An example would be a ``2.1`` branch that is kept up to date with the latest ``2.1.x`` release.
This is most useful for **release branches**, which are maintained over time for a specific release.
An example would be a ``2.1`` branch that is kept up to date with the latest ``2.1.x`` release.

.. _PEP 440: https://www.python.org/dev/peps/pep-0440/

0 comments on commit 1bc451b

Please sign in to comment.