We can use mike [1] to version the documentation, so that if users want to find the documentation corresponding to a particular version of the code they will be able to go back and do so easily. You can see an example setup of this on my github.io page:
A drop down menu will appear in the top left of the webpage allowing the user to select the version. We will have to manually create new versions, which can be done easily when we update the tag by doing
mike deploy --push --update-alias <X>.<Y>.<Z> latest
which will ensure that the latest one points to ..
The CI job will just run and push any changes to the existing latest tag. Before merging this we will need to do a few manual actions to set up the default versions.
We can manually go back and retroactively add old versions documentation if we would like, as I did on the example page above (maybe useful for v8, probably not before that).
We can use mike [1] to version the documentation, so that if users want to find the documentation corresponding to a particular version of the code they will be able to go back and do so easily. You can see an example setup of this on my github.io page:
https://kcormi.github.io/HiggsAnalysis-CombinedLimit/latest/
A drop down menu will appear in the top left of the webpage allowing the user to select the version. We will have to manually create new versions, which can be done easily when we update the tag by doing
which will ensure that the latest one points to..
The CI job will just run and push any changes to the existing latest tag. Before merging this we will need to do a few manual actions to set up the default versions.
We can manually go back and retroactively add old versions documentation if we would like, as I did on the example page above (maybe useful for v8, probably not before that).
[1] https://squidfunk.github.io/mkdocs-material/setup/setting-up-versioning/