Changing the versions.json file often does not reflected in version menu for some time

[anb0s]

Hello

after changing the versions.json file, e.g. adding a new version, and deploying the site it takes some time until the version is shown correctly in the selector drop-down list. The forwarding to new version is done like documented in mike and the URL is correct, but previous version is shown in the selector drop-down list.

Steps to Reproduce

1. change the version.json (add new, and adapt forwarding to new)
2. build the site
3. deploy to S3 bucket or GitLab pages
4. open the target URL
5. The URL shows new version in path, but selector drop-down list shows and selects previous version

Expected Behavior

• the version selector should reflect new version in short time / instant after upload

Additional Context

Clear browser data or opening other browser or incognito mode solves the issue

So the logic to load the version.json and create a drop-down menu must be somewere in the material design theme or mkdocs in a js file, may be there is an issue with handling some caching / cookie etc.?

Any hint how to debug would be helpfull ☮️

ref: follow-up from: jimporter/mike#243

[squidfunk]

This was already answered in jimporter/mike#243 (comment).

[kamilkrzyskow]

Mike is a wrapper around MkDocs, so it could in theory also modify the bundle.js file of the material theme, and replace the versions.json URL with a versions.json?v=latest-available-version URL, which would invalidate the cache immediately like you want after a change.

However, it's probably not the right thing to do, as the maintainer of mike would have to make sure that the override of the versions.json works properly with every mkdocs-material update.

The versions.json also isn't available during the build process for MkDocs to modify the bundle.js with a hook, because we don't know what the latest version is.
However, you could probably make do with a wrapper over mike itself, similar to this approach and modify the bundle.js yourself, like in the example here.

I checked out https://mkdocs-material.github.io/example-versioning/latest/ and the cache header time is set to 600 on GitHub Pages.
I'm assuming it's similar on GitLab, so every 10 minutes it will update for each visitor. I don't think that you release new versions so often that people can't wait for 10 minutes 🤔

EDIT:
Having said all that, you could use a hook like shown here to always modify the bundle.js with the build date versions.json?date=20250521 or something else that would change after each rebuild, and no matter if there is a new version or not the cache would be invalidated.

The "something else" could be the latest version value, in extra.latest_version, maintained manually by hand unrelated to mike.
This is likely the most optimal and easiest approach that would meet the criteria of invalidating the cache for each version change.

EDIT2:
After further consideration, the bundle.js file is also being cached, so changing the URL to version.json might not pan out like we want it to, as it will reuse the previous link from the cached bundle.js. So you'd also need to change the link to the bundle.js inside of the base.html. Similar to how I change it here: #5060