Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #2349
What is the feature
Support for multiple versions of the documentation, allowing users to select and view documentation corresponding to the specific version of the product they are using.
Why we need the feature
Currently, the lack of version information in the documentation leads to several issues:
Uncertainty of Documentation Version: Users are unsure which version of the documentation they are viewing, leading to confusion.
Discrepancies with Older Versions: Users operating on older versions of the product may find inconsistencies between the documentation and the actual product features.
Outdated Information: Users might inadvertently reference outdated documentation (e.g., viewing installation instructions for version 0.9 when version 0.11 is available) without realizing it, even after refreshing the page.
By supporting multiple versions, we ensure that all users have access to accurate and relevant documentation, enhancing the user experience and reducing potential frustration.
How to implement and why
Step 1: Version Control
v0.9
,v0.10
,v0.11
).Reason: This establishes a clear record of changes and allows us to generate documentation for each specific version.
Step 2: Separate Documentation Builds
sphinx-multiversion
extension.Reason: Separate builds ensure that the documentation accurately reflects the state of the codebase at each version.
Step 3: Update Documentation Hosting
/docs/v0.9/
,/docs/v0.10/
).Reason: This structure allows users to access different versions via distinct URLs, maintaining clarity and accessibility.
Step 4: Implement Version Selector UI
Reason: A user-friendly interface enables users to easily switch between versions without confusion.
Step 5: Redirects and Notices
Reason: This helps prevent users from relying on outdated information and guides them towards the most recent documentation when appropriate.
Step 6: Continuous Integration Updates
Reason: Automation reduces the risk of human error and ensures consistency across all documentation versions.
About backward compatibility
This feature enhances backward compatibility by providing documentation for all supported versions of the product. It does not introduce any breaking changes to the codebase or existing infrastructure. Instead, it improves the overall usability for users on older versions, ensuring they have access to accurate and relevant information without impacting users of the latest version.
Test these changes locally