Documentation: support versioned docs #2408
Conversation
|
@btashton the next step would be to extend the website build to go over each version to document, build it (exposing the list via the variable each time) and place it under the expected location. I can only think of a loop over the variable, checking out one tag at a time. Maybe you have a better idea on how to achieve it. |
|
Yeah that's basically what I was thinking. We can figure out what we need to do for the tag if we don't even up needing an RC1. One option is just to patch it. I'm also not sure if the sphinx action is gaining us much so if it ends up easier to do this in a script that seems reasonable. We should be aware we might need a new virtual environment for each build of the docs as the dependencies might change. |
|
We can also make an extra test tag like 0.0.0 if that would be helpful to test this. |
We can leave this for next release worst case, it is not that urgent. BTW, if RC0 is final shouldn't we tag it as such (ie: 10.0)? A "RC" tag gives the impression of non-final release. It could be simply another tag to the same commit.
I agree, I was just looking into what the action does. If we could make a call to pipenv shell just like a local build for each tag, that would be the best case I think. |
Unfortunately we have to tag the RC we cannot change the commit without having to go through the whole release voting cycle again... So once we have an approved release I add the non RC tag to the approved RC commit. That said usually we have 2 or 3 RC anyway, and I would not expect this to be different. Hard to get testing before the RC is made. |
Yes, that was what I was referring to |
Summary
This makes the version selector in the documentation to be functional. On a local build the selector will always show "latest" and will not be usable, but the Makefile now will now read the NUTTX_VERSIONS environment variable, which can be either empty (the usual) or have a list of comma-separated nuttx version names (eg: "10.0,10.1"). This will populate the selector and the documentation will go to /. The "latest" version is always defined and does not need to be added to NUTTX_VERSIONS.
To complete support for this, a change needs to be done on the website to pass the list of versions to expose via this variable.
By supporting this via an environment variable, every version of the documentation will have links to all exposed versions (since it is not a hardcoded list in the documentation). So to have this on final 10.0 release, we would have to merge this before generating the final tag.
Impact
Documenation
Testing
Tested by defining NUTTX_VERSIONS locally.