Now that we have a new version scheme fully rolled out (https://github.com/iree-org/iree/issues/18938, https://iree.dev/developers/general/versioning-scheme/), we can plan towards publishing multiple versions of our documentation. While I expect that most users will only want to view the latest version and this can dilute search results (without tricks like excluding older versions using robots.txt), hosting documentation for older versions can be useful for users that are slower to update and developers that may want to see older content outside of the git history.
If this ends up bloating the gh-pages branch too much by multiplying its size, we could move the documentation out into a separate repository. I'd prefer to keep the docs closer to the code though.
When we tag a release like the latest https://github.com/iree-org/iree/releases/tag/iree-3.0.0, we could use a tag like v3.0.0 that readthedocs will detect and swap that "latest" requirement for an exact requirement matching the release, e.g. 3.0.0. Depending on when we branch/tag and when we push stable, promoted packages to PyPI, we could also pin to the release candidate version like 3.0.0rc20241118.
Now that we have a new version scheme fully rolled out (https://github.com/iree-org/iree/issues/18938, https://iree.dev/developers/general/versioning-scheme/), we can plan towards publishing multiple versions of our documentation. While I expect that most users will only want to view the latest version and this can dilute search results (without tricks like excluding older versions using robots.txt), hosting documentation for older versions can be useful for users that are slower to update and developers that may want to see older content outside of the git history.
Project website
For https://iree.dev/, see
If this ends up bloating the
gh-pagesbranch too much by multiplying its size, we could move the documentation out into a separate repository. I'd prefer to keep the docs closer to the code though.Showing created and last edited dates is semi-related: https://github.com/iree-org/iree/issues/15723.
Python API documentation
For https://iree-python-api.readthedocs.io/, see
We currently fetch the latest nightly versions for documentation builds on readthedocs: https://github.com/iree-org/iree/blob/b9d73cf6f3316ed83594b9608d52315a5ef476cf/docs/api_docs/python/.readthedocs.yaml#L8-L10 https://github.com/iree-org/iree/blob/b9d73cf6f3316ed83594b9608d52315a5ef476cf/docs/api_docs/python/requirements.txt#L15-L19
When we tag a release like the latest https://github.com/iree-org/iree/releases/tag/iree-3.0.0, we could use a tag like
v3.0.0that readthedocs will detect and swap that "latest" requirement for an exact requirement matching the release, e.g.3.0.0. Depending on when we branch/tag and when we push stable, promoted packages to PyPI, we could also pin to the release candidate version like3.0.0rc20241118.See also https://github.com/iree-org/iree/issues/5477 for other API documentation topics.