Issue #1642. Operators and integrators on an older release need docs that match the contracts and API they actually run. This page covers how documentation versions are defined, how to switch between them, how each version is maintained, and when a version is deprecated.
- How versions work
- Switching versions
- Cutting a new version
- Maintaining older versions
- Deprecation policy
- Manifest reference
Documentation versions are git refs, not copies of docs/ inside the tree.
Copies would double the size of docs/, confuse the docs index and link
checks, and drift the moment someone forgets to update both.
| Version | Git ref | What it documents |
|---|---|---|
latest |
main |
Unreleased work on main. Always the default. |
MAJOR.MINOR (e.g. 1.0) |
branch docs/vMAJOR.MINOR |
The release line with that contract version (see contracts/quorum_proof/src/version.rs). |
Patch releases (1.0.1, 1.0.2) share their minor version's docs. A patch
never changes a public interface, so it doesn't need a separate docs version.
The list of versions and their status lives in
versions.json. The interactive docs version switcher
reads it, and scripts/docs_versions.py manages it.
Interactive docs. Open docs/interactive/ (see
interactive-documentation.md) and pick a
version from the Docs version menu in the header. Search result links
then open that version's copy of each page on GitHub. If the version is
deprecated or at end of life, a banner shows the dates. Your choice is saved
in the URL (?v=1.0), so you can share the link.
The search index is always built from latest. A page that was added after
an older version was cut won't exist on that version's branch, and its link
will 404.
GitHub. Use the branch selector, or change the ref in the URL:
https://github.com/QuorumProof/QuorumProof/blob/main/docs/deployment-guide.md # latest
https://github.com/QuorumProof/QuorumProof/blob/docs/v1.0/docs/deployment-guide.md # v1.0
Locally.
git fetch upstream
git worktree add ../quorumproof-docs-v1.0 upstream/docs/v1.0
# read ../quorumproof-docs-v1.0/docs/A maintainer cuts a docs version as part of every minor or major release,
right after the release commit lands on main:
python3 scripts/docs_versions.py cut 1.1 # branch docs/v1.1 from HEAD, add to manifest
git push upstream docs/v1.1
git add docs/versions.json
git commit -m "docs: cut documentation version 1.1"Use --ref <sha> to branch from the release commit if main has moved on.
Cutting a new version doesn't deprecate the older ones on its own. Apply
§5 as a separate step.
-
Fix on
mainfirst, then backport. Cherry-pick the docs commit onto every supporteddocs/vX.Ybranch it applies to:git checkout -b backport/1.0-fix-typo upstream/docs/v1.0 git cherry-pick -x <sha> # open a PR against docs/v1.0
-
Backport only what's true for that version. If a fix describes behaviour that changed after the version was cut, rewrite it for the old behaviour. Don't cherry-pick it as-is.
-
What gets backported, by version status:
Change supporteddeprecatedeolSecurity advisories / security-relevant corrections Yes Yes Yes (banner only) Factual errors, broken commands, broken links Yes Yes No Clarifications, new examples Yes No No Docs for new features No: those go in latestonlyNo No -
Pull requests against a
docs/vX.Ybranch follow the normal review process. Put[docs vX.Y]at the start of the title so reviewers can see which branch it targets. -
The manifest on
mainis the only source of truth for status. Don't editversions.jsonon version branches.
Each docs version moves through these states:
supported ──(deprecate)──▶ deprecated ──(180 days)──▶ eol
| Status | Meaning |
|---|---|
current |
latest (main) only. |
supported |
Fully maintained per §4. |
deprecated |
Security and correctness fixes only. The switcher shows a warning with the EOL date. |
eol |
No longer maintained. The branch is kept read-only for history and the switcher shows an end-of-life banner. |
Rules
- We maintain at least the two most recent minor versions as
supported. - When a new minor or major version is cut, a version that falls outside that
window is deprecated:
python3 scripts/docs_versions.py deprecate 1.0 # EOL defaults to +180 days python3 scripts/docs_versions.py deprecate 1.0 --eol 2027-06-30 - A deprecated version reaches end of life 180 days after deprecation, unless the release notes announced a longer window. A new major version gives the previous major a window of at least 365 days.
- Deprecations are announced in the release notes, and in the docs themselves through the switcher banner.
- When the EOL date passes, a maintainer runs
python3 scripts/docs_versions.py eol <version>.eolbranches are never deleted, because old links must keep working. - The contract-level upgrade and migration docs
(contract-upgrade-guide.md,
user-credentials-migration.md) on
latestmust always explain how to upgrade from every non-EOL version.
docs/versions.json:
{
"schema": 1,
"repository": "https://github.com/QuorumProof/QuorumProof",
"default": "latest",
"versions": [
{ "version": "latest", "label": "Latest (main)", "ref": "main",
"status": "current", "released": null, "deprecated": null, "eol": null },
{ "version": "1.0", "label": "v1.0", "ref": "docs/v1.0",
"status": "deprecated", "released": "2026-10-01",
"deprecated": "2027-04-01", "eol": "2027-09-28" }
]
}| Field | Description |
|---|---|
version |
latest or MAJOR.MINOR. |
label |
Name shown in the version switcher. |
ref |
Git ref the docs are read from. |
status |
current, supported, deprecated or eol. |
released / deprecated / eol |
ISO dates (YYYY-MM-DD) or null. eol is required once a version is deprecated. |
To validate the manifest, run python3 scripts/docs_versions.py check.
It checks that exactly one version is current, that statuses and dates are
valid, and that every deprecated or EOL version has an EOL date.