Description
Having docs build both the latest tag and the current checkout has been a continual source of pain, the latest version being in 4ecbf35. Each checkout of cclib should handle its docs build alone.
The single website with both release and dev docs is nice, especially in the absence of the Read The Docs-like mechanism for switching between docs versions. A few options come to mind:
- Create a wrapper that takes a Git revision, then clones the repo at that revision and does a docs build. A wrapper around that wrapper does this for the dev+latest versions and merges them together, possibly with other stuff. This seems difficult.
- Rather than have a wrapper that combines dev+latest release, simplify further by doing what all other projects do: docs are for the current version only. The problem here, if we don't have a version picker like in Read The Docs, then what's on the docs website is the development docs, not the release. This can be misleading.
The way Read the Docs seems to do it, as by looking at https://docs.pytest.org/en/stable/getting-started.html and https://readthedocs.org/projects/pytest/versions/, is that there's a build for each branch, latest is the main branch, and stable is the newest tag. I also see latest and stable in our currently-not-used RTD dashboard at https://readthedocs.org/projects/cclib/. A third option may be to take option 2 and figure out how to properly get latest+stable on RTD. This would also required re-adopting RTD and having cclib.github.io point to the RTD site. If the redirection isn't possible, we'd ditch GitHub Pages, since differences between that and RTD caused confusion in the past.