Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GitAuto: 建议支持多版本 #5723

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

gitauto-ai[bot]
Copy link
Contributor

@gitauto-ai gitauto-ai bot commented Oct 11, 2024

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:

  1. Uncertainty of Documentation Version: Users are unsure which version of the documentation they are viewing, leading to confusion.

  2. Discrepancies with Older Versions: Users operating on older versions of the product may find inconsistencies between the documentation and the actual product features.

  3. 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

  • Tag each release of the product in the repository with a version identifier (e.g., v0.9, v0.10, v0.11).
  • Maintain separate branches for each major version if necessary.

Reason: This establishes a clear record of changes and allows us to generate documentation for each specific version.


Step 2: Separate Documentation Builds

  • Configure the documentation build process to generate separate sets of documentation for each version.
  • Utilize documentation tools that support versioning, such as Sphinx with the 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

  • Organize the documentation on the hosting platform to include version directories (e.g., /docs/v0.9/, /docs/v0.10/).
  • Set up a default version (typically the latest stable release) that users are directed to by default.

Reason: This structure allows users to access different versions via distinct URLs, maintaining clarity and accessibility.


Step 4: Implement Version Selector UI

  • Add a version selection dropdown or menu to the documentation site.
  • Ensure that the selector is prominently displayed on all documentation pages.

Reason: A user-friendly interface enables users to easily switch between versions without confusion.


Step 5: Redirects and Notices

  • Implement redirects for outdated or removed pages to guide users to the appropriate content.
  • Display notices on older version documentation indicating that a newer version is available.

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

  • Update CI/CD pipelines to automate the documentation build and deployment process for each version upon release.
  • Ensure that documentation updates are included as part of the release process.

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

git checkout -b gitauto/issue-#2349-50e5fbd4-3e41-46e6-85b1-e55fdcdd0bd6
git pull origin gitauto/issue-#2349-50e5fbd4-3e41-46e6-85b1-e55fdcdd0bd6

@gitauto-ai gitauto-ai bot mentioned this pull request Oct 11, 2024
@github-actions github-actions bot added develop size/S A PR that changes 10-29 lines and removed develop labels Oct 11, 2024
Copy link

netlify bot commented Oct 11, 2024

Deploy Preview for daocloud-docs ready!

Name Link
🔨 Latest commit 493be47
🔍 Latest deploy log https://app.netlify.com/sites/daocloud-docs/deploys/67086bc245f6180008c84bdd
😎 Deploy Preview https://deploy-preview-5723--daocloud-docs.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@samzong
Copy link
Member

samzong commented Oct 15, 2024

This is unrelated to demand and cannot achieve multiple versions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
develop size/S A PR that changes 10-29 lines wip-do-not-merge work in process
Projects
None yet
Development

Successfully merging this pull request may close these issues.

建议支持多版本
2 participants