Description
Context
Currently, we ask users to provide two things for the version switcher: a name
and a version
.
[
{
"name": "v2.1 (stable)",
"version": "2.1"
},
{
"version": "2.0"
},
{
"version": "1.0"
},
]
The documentation is then configured with a URL template like https://mysite.org/en/version-{version}/
.
We then interpolate the URL of each version according to the template.
However, there are a few limitations of this approach:
- It assumes that the URL structure of each version is the same
- The structure of URLs is strongly tied to each Sphinx build.
- This means that if there are bugs that generate wrong URL links, it's non-trivial to fix them
- It also means that if the structure of those versions changes, it's non-trivial to fix them.
Proposal: users should give explicit links in the JSON
Instead of interpolating a link structure based on a template, we could just ask users to provide a url:
key for each entry in the JSON configuration. For example, the above structure would become:
[
{
"name": "v2.1 (stable)",
"version": "2.1",
"url": "https://foo.org/en/stable/"
},
{
"version": "2.0",
"url": "https://foo.org/en/2.0/"
},
{
"version": "1.0",
"url": "https://foo.org/en/1.0/"
},
]
Then, when the Dropdown list is built, there isn't any interpolation, it simply generates a dropdown list of links with names.
I think this has a few benefits:
- It reduces the complexity and assumptions we need to make in generating these lists. I suspect there will be fewer "unexpected surprises" with this implementation, as we recently experienced with the
v
bug. - It makes the main JSON configuration more of a "source of truth" and explicit where the versions will point
- It shields us from any bugs or UX problems associated with the need to make changes that depend on a specific Sphinx build.
It does mean slightly more hand-editing of that JSON configuration, but I think that this won't be too bad for most projects. I assume most will only keep maybe 6-12 versions in there, and even larger numbers of versions won't be hard to hand-edit with modern-day text editors.
An added bonus is that it would then be pretty trivial to generate a language dropdown. You'd simply have a second JSON configuration file, with URLs that corresponded to language versions instead of code versions.
ref: this also relates to a bug that was pointed out in #574 (comment)