Christian Schwarz 8b0637ddcc docs: switch to sphinx-multiversion for multi-versioned docs (#734) ... The sphinxcontrib-versioning seems unmaintainted and I can't get the fork that we used before this PR working on Python 3.10. The situation wrt maintenance doesn't seem much better for sphinx-multiversion, but, at least I could get it to work with current sphinx versions. The main problem with sphinx-multiversion is that it doesn't render anything at `/`. I.e., `https://zrepl.github.io/configuration.html` will be 404. That's different from `sphinxcontrib-versioning`, and thus switching to sphinx-multiversion would break URLs. We host on GitHub pages and don't control the webserver, so, we can't use webserver-level redirects to keep the URLs working. We could create JS-level redirects, or `http-equiv`, but that's ugly as well. The simplest solution was to fork sphinx-multiversion and hard-code zrepl's specific needs into that fork. The fork is based off v0.2.4 and pinned via requirements.txt. Here are its unique commits: https://github.com/Holzhaus/sphinx-multiversion/compare/master...zrepl:sphinx-multiversion:zrepl We should revisit `sphinx-polyversion` in the future once its docs improve. See https://github.com/Holzhaus/sphinx-multiversion/issues/88#issuecomment-1606221194 This PR updates the various Python packages, as I couldn't get sphinx-multiversion to work with the (very old) versions that were pinned in `requirements.txt` prior to this PR. This PR's `requirements.txt` is from a clean Python 3.10 venv on Ubuntu 22.10 after running ``` pip install sphinx sphinx-rtd-theme pip install 'git+https://github.com/zrepl/sphinx-multiversion/@52c915d7ad898d9641ec48c8bbccb7d4f079db93#egg=sphinx_multiversion' ```		2023-09-09 12:21:25 +02:00
..
config.yml	docs: switch to sphinx-multiversion for multi-versioned docs (#734)	2023-09-09 12:21:25 +02:00
trigger_debian_binary_packaging_workflow.bash	build: extract debian binary packaging workflow trigger into a reusable script	2020-07-26 20:32:35 +02:00