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
Consider readthedocs style handling of multiple versions #1373
Comments
Imagined url structure:
Any "versioned" (e.g. devel or tagged release) site would set the canonical url to the root. How would github builds work? Regular builds go in devel. Tagged builds make two versions — one is versioned in Would have ndjson file in root directory that's updated by versioned release — release just appends new version to end (so we can use union strategy to avoid merge conflicts) |
|
An example from python: https://pydata-sphinx-theme.readthedocs.io/en/stable/user_guide/version-dropdown.html |
Hi! Last week I worked on implementing Appsilon/rhino#530. As a result I created a build script which creates a site with multiple versions of documentation and a switcher. You can view a demo at https://tymekdev.github.io/rhino. This endeavor gave me a good overview of the issue and how to approach it. I will describe how the build script works and its shortcomings. I will also describe what decisions I think would have to be made before implementing this feature directly in pkgdown. Hopefully, this gives a good overview on the matter. Let me know what do you think! Best, Build ScriptGoals
DescriptionA version is tied to a git ref (~revision), and defined by:
Note I considered using historical versions from CRAN, however I learned that these might not have vignettes included. Key components to this solution is a build script and a navbar template template (no, I did not stutter 🙃). Usagesource("pkgdown/build.R")
build_versioned(
repo = ".",
versions = list(
list(
ref = "refs/remotes/origin/main",
href = "/dev",
label = TRUE # takes version from DESCRIPTION and appends "(dev)" to it
),
list(
ref = "refs/tags/v1.7.0",
href = "/",
label = "1.7.0"
),
list(
ref = "refs/tags/v1.6.0"
href = "/v1.6.0",
label = "1.6.0",
)
),
url = "https://appsilon.github.io/rhino",
destination = "docs"
) Important Why not revision instead of ref? Step by Step
ResultRunning the code presented above would create a directory with a following structure:
This way any static file server will get the job done and get the paths right. As you can see it working on GitHub pages. Issues and Caveats
I am quite sure that all of these could be addressed. However, this would be a significant effort - comparable if not bigger than adding a proper support to pkgdown itself. Additionally, 6. can be treated as an extra. See how an old Bootstrap versions have a banner that just switches to an index page of the newest version. Extending pkgdownBelow you can find the burning questions that, in my opinion, would have to be answered before implementing this feature. Decide how versions are definedThere is quite a lot of room for automation here. A couple ideas:
An MVP could use explicitly listed git revisions (as in the build script above). Decide how to approach canonical URLs, indexing, and sitemap.xmlThis gets tricky with adding a canonical URL to an older versions as content might get removed. There would have to be a detection mechanism to see if something disappeared in a later version (what is a "later" version, though?). However, implementing this detection mechanism would make the following possible:
An MVP could simply index only the "stable" version (with What to override in older versionsURL is a must. Styling would not be necessary4. Perhaps an equivalent of An MVP could just override the URL. Footnotes
|
(with a few tweaks for our needs)
/version/...
(also need to be able to run locally in case automation fails or otherwise needs update)The text was updated successfully, but these errors were encountered: