Our documentation is versioned. All sections are versioned together, this includes products that do not have a fixed release cycle (such as Console, Web Modeler, and Connectors).
Depending on the version, location of source files and sidebar navigation definition varies:
Instance | Version(s) | Source path | Sidebars path |
---|---|---|---|
docs |
Next | /docs/ | sidebars.js |
docs |
8.7, 8.6, 8.5, ... | /versioned_docs/version-*/ | versioned_sidebars/version-*-sidebars.json |
New versions are created as part of the release process.
Docusaurus builds the documentation for all versions in the project, even those that are no longer supported. With a large number of versions, this can slow down the build process significantly. We archive versions that are no longer supported to speed up build workflows.
Our current policy is to support versions for 18 months. Any version older than 18 months is suitable for archiving.
When a version is archived, it is removed from the main docs, isolated on a branch named unsupported/x.xx
where x.xx
is the version, and deployed to the URLs https://unsupported.docs.camunda.io/x.xx/
and https://stage.unsupported.docs.camunda.io/x.xx/
.
See this 8.3 archival issue for an example of all required steps.
- Create a new branch named
unsupported/x.xx
wherex.xx
is the version to be archived. The branch should be created from the latest commit on themain
branch. - On the
main
branch:- Configure the
publish-prod
workflow to ignore tags for the archived version. See this PR as an example.- It's important to do this before publishing a production release for the archived version, to avoid accidentally publishing the archived version as the main docs.
- Configure the
- On the
unsupported/x.xx
branch:- Confirm the version number to be archived at the top of the
./hacks/isolateVersion/allSteps.sh
script. - Run the
./hacks/isolateVersion/allSteps.sh
script. This automates a handful of basic steps; see the script for more details.- For the sake of review-ability, consider breaking these changes into multiple PRs. See this very large PR and this much smaller PR as examples.
- Make the manual changes described by the output of the
allSteps.sh
script. See this PR as an example. - After they're all merged, confirm that these changes publish to the associated staging location:
https://stage.unsupported.docs.camunda.io/x.xx/
. - Publish the production release for the archived version, by adding a tag to the HEAD of the
unsupported/x.xx
branch.- Name the tag
x.xx.0
wherex.xx
is the version number. - Choose the
unsupported/x.xx
branch as the target. - Deselect the
Set as the latest release
option.
- Name the tag
- Confirm the version number to be archived at the top of the
- On the
main
branch:- Remove the archived version from the docs.
- Publish a new patch release of the main docs.
The Docusaurus documentation provides a detailed explanation of versioning at https://v2.docusaurus.io/docs/versioning/.