<outsidecontext[m> "Regarding readthedocs I have..." <- I vaguely remember that there were two reasons... One was so that I could intercept and redirect the requests where I had renamed a couple of pages from what Picard was requesting (my mistake), and the other to provide the ability to deliver the tag list as a spreadsheet. I think a third reason was that I didn't understand how to properly handle other
languages in RTD. I think all can be accommodated in RTD, but I'll do some testing first to make sure. I'll also have to look into how to handle translations AND multiple versions of the documentation on RTD. I think switching to RTD is something that I'll leave until later because the current setup seems to be working for now. I just have to think about what needs to be considered in the repo setup and
structure to allow the change in the future.
outsidecontext[m
Agreed, yes. Maybe RTD would make maintenance easier in the long term, not sure though
BobSwift[m]
In looking at this a bit more, I'm not sure moving to RTD will actually make maintenance any easier. I think only maintaining major versions (eg. 2.x, 3.x, etc.) will be the biggest simplification, and it should be relatively easy to implement.
Of course, I'd like to keep the latest and stable version specifiers as well (to be consistent with ReadTheDocs URL format). I just need to think a bit about what these should point to. For example, should latest point to the latest version of Picard that has been release (including Alpha, Beta or Release Candidate), and stable point to the latest version that isn't a pre-release version (Alpha, Beta or
RC)? Once we agree on what is expected, then setting up the workflow should be fairly easy.
* Of course, I'd like to keep the latest and stable version specifiers as well (to be consistent with ReadTheDocs URL format). I just need to think a bit about what these should point to. For example, should latest point to the latest version of Picard that has been released (including Alpha, Beta or Release Candidate), and stable point to the latest version that isn't a pre-release version (Alpha, Beta
or RC)? Once we agree on what is expected, then setting up the workflow should be fairly easy.
One other thing I have in mind is to remove all the image files from the gh-pages branch and load them into the displayed pages using links to the main repo. This should save a ton of storage space because copies of the images are currently stored for each language for each version of the documentation, which means right now we're storing 22 copies of (mostly) the same approximately 130 image files in the
gh-pages branch. That's something I should have considered when I first set it up. If we can limit the gh-pages branch to just holding the text files for the site, that should be much more efficient. This is one of the first things I want to do.
