[SwayamInSync]

The site was built from main alone, and the release archives link to it. So once 0.2 changes merged, a user of 0.1.1 read about behavior their binary does not have: the changes since 0.1.1, the new release notes section, and from #48 on, options 0.1.1 does not accept.

The site now has one version of the documentation per release series, plus the development version:

Path	Documents	Built from
/	The latest release (0.1.1)	Its tag
/X.Y/	Each release series (/0.1/)	The series' latest tag; before its first release, its latest candidate
/dev/	The development version (0.2.0-dev)	main

The root keeps documenting the release, so every existing link (the README's, the 0.1.x archives', bookmarks) keeps working and keeps showing what a release does. /0.1/ is the stable path to the same pages.

• website/scripts/build-site.sh builds each version from its own sources: this tree for /dev/, and for each series the files of its tag, taken with git archive (no checkout). Each build runs Doxygen, Sphinx with -W, and the book's sidebar check, as build-docs.sh does. The title and a banner come in through -D, so an old tag's conf.py needs nothing new:

  • /dev/: "This is the documentation of the development version, 0.2.0-dev, built from main. The latest release is 0.1.1: its documentation."
  • The latest release: "This is the documentation of cpp-verify 0.1.1, the latest release. The development version documents what main adds."
  • An older series: "This is the documentation of cpp-verify X.Y.Z. The latest release is ...".

  Titles name the version (Commands and flags - CppVerify 0.1.1). Before any release, the development version is also the root.

• cppverify-docs.yml fetches the tags and publishes website/site. Pull requests build the whole site too, so a change that breaks an old version's build shows up there.

• The github-pages environment allows deployment from main only, so a tag cannot publish. cppverify-release.yml therefore runs the documentation workflow on main once it has created a release, which adds the new tag's series. Its README.txt and release notes now link to the series of the release, /X.Y/, instead of the root. A candidate, such as 0.2.0-rc.1, is documented at /0.2/ until 0.2.0.

I chose the root as the latest release, rather than /dev/ or a redirect page, because that is the one layout under which no published link moves. It is the decision to look at before merging: deploying it changes what the site's root shows from main to 0.1.1.

Docs: website/README.md describes the layout and how it is built and published, the README links to the development version, and the release notes get an entry under "Running cpp-verify".

Checked:

• build-site.sh builds the site locally (in a virtual environment with website/requirements.txt). The root and /0.1/ show 0.1.1, /dev/ shows 0.2.0-dev, and every page has its banner, the deep pages of each version included. Each version has its Doxygen pages.
• The selection of tags, run on a made-up list (v0.1.0-rc.1 v0.1.0 v0.1.1 v0.2.0-rc.1 v0.2.0-rc.2 v0.2.0 v0.10.0-rc.1 llvmorg-23.1.3), gives 0.10 v0.10.0-rc.1, 0.2 v0.2.0, and 0.1 v0.1.1, with v0.2.0 at the root. Without v0.2.0, it gives 0.2 v0.2.0-rc.1, with v0.1.1 at the root.
• Both workflows parse as YAML.
• The documentation workflow's build passed on this PR (run 39518402730): it built dev and 0.1 from the fetched tags and uploaded the site. The deploy runs on main only, so the first push to main after the merge publishes it. The release workflow's new step runs only when a release is published.
• This merges cleanly with each open PR, verify: Reject valid(p, n) outside a precondition #40 to verify: Bound what a run builds and what its solvers allocate #48.

The release checklist in the private notes gets the new step.