For the Besu documentation repositories, a new stable version of the documentation is released when a new version of the Besu software is released.
The process consists of one manual action and two automatically triggered actions:
1. Manually create a release on GitHub
When a new version of the software is released, the documentation team manually creates a release on the corresponding GitHub documentation repository.
Documentation versioning follows the same Calendar Versioning (CalVer) pattern as the software to help users match the documentation version to the software version easily.
The GitHub release creation process tags the Git repository with the new version (for example, 21.1.4).
2. Automatically build the documentation on RTD
When Read the Docs (RTD) detects a new tag on a documentation repository, RTD automatically generates the following documentation versions:
- Latest - Corresponds to the latest commit in the main branch of the documentation repository.
- CalVer - Corresponds to the tag in the main branch that was created during the release (for example,
21.1.4). - Stable - Corresponds to the last created tag.
RTD builds all three versions, all showing the same content from the same commit.
As contributors continue to work on the documentation, RTD rebuilds the latest version from the latest main commit each time a new PR is merged, and the CalVer and stable versions remain behind latest.
Note: The Besu documentation repository default branch is now named main.
3. Automatically activate the documentation version on RTD
By default, RTD doesn’t activate or publish new CalVer versions, but Besu documentation has custom rules for RTD to automatically do so. If you have access to RTD as a Besu documentation maintainer, you can view these automation rules and the history of version activations in the Admin tab of the RTD documentation project.