Bump to dev version + update versions in switcher.json

[jorisvandenbossche]

Related to the discussion in #556, and trying to improve the versions in the dropdown in our own demo docs.

cc @drammock

• I added stable and latest versions, and therefore needed to remove the harcoded "v" in the template url
• I trimmed down the list of versions a bit

[damianavila]

Highlighting this comment from another PR: #576 (comment)

[choldgraf]

I rebased on master and pushed a commit that:

• Added a check for the READTHEDOCS_VERSION variable, and uses it if found
• Added extra_classes for stable and dev to see if this works

[damianavila]

Added extra_classes for stable and dev to see if this works

When I check for the class on the RTD deployment of this PR, I do not see "dev" the extra class...

@choldgraf, can you confirm this is the case for you as well?

[damianavila]

@tupui, since you implemented #576, do you have any thoughts?

[tupui]

But the json is not deployed. This is the issue no? Or are you checking by manually pointing to this PR's json?

[damianavila]

But the json is not deployed.

You are right... I forgot about that 😉
This is in fact confusing if you have a weak memory like me... I think we might find a way to actually "see" changes on the version-switcher-related stuff on RTD previews, but that is another discussion!

[jorisvandenbossche]

Thanks for the updates! Since we will only really see how it goes once merged, let's merge this

[jorisvandenbossche]

Hmm, so the dropdown is not working. But that might actually already be an issue with #576?

It's giving an error in the console: Uncaught TypeError: $(...).classList is undefined, which is pointing to

pydata-sphinx-theme/src/pydata_sphinx_theme/theme/pydata_sphinx_theme/_templates/version-switcher.html

Line 79 in 0c77b6d

$("#version_switcher_menu").classList.add(...entry.extra_classes);

[tupui]

@jorisvandenbossche sorry about that. But please see #597 as @choldgraf was changing the logic to not rely on JS here.

[jorisvandenbossche]

No problem. And yes, I saw that PR, but I thought this could go in first, so we could ensure #597 would ensure the same behaviour ..

[tupui]

Got it, sorry cannot really help a lot here. I got help for the syntax at the end. I originally had a for loop and I recall testing it locally and I believe it was working.

[damianavila]

$("#version_switcher_menu").classList.add(...entry.extra_classes);

You might need to get the actual node with jquery... I think something like the following (untested) might work?

$("#version_switcher_menu")[0].classList.add(...entry.extra_classes);

[damianavila]

OK, here you have a PR #599 fixing this one among other things I have talked about in my above comments (hopefully 😉):

This is in fact confusing if you have a weak memory like me... I think we might find a way to actually "see" changes on the version-switcher-related stuff on RTD previews, but that is another discussion!

[damianavila]

Btw, there is another issue with this PR... if you land into stable: https://pydata-sphinx-theme.readthedocs.io/en/stable/ and try to go any other version, it will fail, ie. https://pydata-sphinx-theme.readthedocs.io/en/vv0.7.2/
Notice the vv0.7.2. I think we may need to make a 0.8.1 release when #599 is merged so stable can actually redirect properly to other versions... although 0.8.0 will be always broken 😢? (unless we literally hack something to fix it... although it is late here and I might be missing something).

[choldgraf]

IMO we should fix it, release 0.8.1, and then remove 0.8.0 from existence in the dropdown - in general, I only think we need to display the versions of the latest release on a major version (or, for each minor release for now maybe)

[jorisvandenbossche]

Btw, there is another issue with this PR... Notice the vv0.7.2.

Ah, good catch, I didn't think about that when changing the url_template ..
We can now indeed fix it in 0.8.x, and remove 0.8.0 from the dropdown.

But assume that the dropdown already had existed for a longer time (eg also in 0.6 and 0.7 docs), then this would not have been that easy to "fix". So this points a bit to an inherent limitation of changing things in future versions after an initial set-up? Which makes our current approach not super robust to changing urls?
Although you can probably always fix it by using full urls instead of the url template, thanks to #575 (I suppose this is the generic solution for projects that might change url template at some point, but want to keep working links in older docs?)

[choldgraf]

That's a good point @jorisvandenbossche - I'm actually wondering if the approach you describe - giving fully-resolved URLs instead of a template - is actually a better solution in general with less complexity. I'll write up an issue to discuss

[choldgraf]

👉 #600