There are various factors causing modules to invalidate and change their version timestamp or hash. Which in turn invalidates many caching layers, such as minification cache, varnish cache, browser HTTP cache, and client-side localStorage cache.
Goal to measure success:
When upgrading MediaWiki from one wmf-branch to the next, modules shouldn't invalidate their cache. Only if the module content changed (e.g. scripts, styles and other included resources).
Known problems are listed below.
- File modules use timestamps that don't persist. With the way Wikimedia deploys MediaWiki right now, each upgrade involves a fresh clone with Git. As such, while Git only changes timestamps on-disk when files changed between checkouts, a new clone will always have the current timestamp for each file created during the clone.
- Modules with messages use localisation cache timestamp. This one can be observed best on a local wiki with caching disabled. Modules with messages have a different version every time the startup module is generated.
- File modules include absolute paths in their definition summary. (e.g. localBasePath, which is $IP, which at Wikimedia is a directory that includes a MediaWiki branch names like 1.26wmf4).
- Undo/redo results in different versions. Users that skipped the intermittent state needlessly re-fetch resources.