Releasing a new stable version of the documentation is to be done when the software new version is released.
The process is composed of 1 manual action and 2 automatically triggered actions:
- Manually create a release on Github.
- Automatically build the newly released doc.
- Automatically activate newly released doc version.
Github repository release manual actions
Documentation versioning follows the exact same Calendar Versioning (CalVer) pattern as the software to enable users to find the documentation matching their software version easily.
This is done by creating a release on the Github documentation repository : https://github.com/hyperledger/besu-docs/releases
The Github release creation process creates a tag in the Git repository and a Github release that will trigger the build of the new documentation version on Besu Read The Docs project.
This part must be done manually by the release team.
Read The Docs automatic webhook triggered build
Read The Docs (RTD) will generate the following versions when a new tag is detected on the repository:
- Latest: corresponds to the latest commit in the master branch of the doc repos
- CalVer version (for example: "21.1.4"): corresponds to the tag in the master tat was created during the release
- Stable: corresponds to the last created tag (for example 21.1.4)
When creating a release, RTD will build 3 versions : latest, CalVer version and stable and they will all show the same content from the same commit.
But then when contributors will continue to work on the doc, the latest will be rebuilt from the latest master commit each time a new PR is merged and the CalVer version and stable will be behind latest.
Read The Docs version automatic activation
By default, new doc CalVer version are not activated by RTD, but we have a setup that tells RTD to activate CalVer numbered versions automatically once built: https://readthedocs.org/dashboard/hyperledger-besu/rules/
You can check the history of activations on this page as a maintainer.