Change Details

This is about all caches related to ResourceLoader: * minification cache. * any tracked timestamps (of on-disk files, or other objects). * definition summaries. * module versions (as included in the startup manifest). * localstorage cache (cache key should remain the same). Known issues that prevent this are listed below. These currently cause web clients to have to re-download modules that are effectively unchanged, but are needlessly being invalidated when upgrading a wiki to a newer wmf branch: * [ ] File modules include `localBasePath` in their definition summary, which includes the absolute path to `$IP`, which for wmf-production includes the mediawiki deployment tag (e.g. `1.26wmf4`). * [ ] File modules track file timestamps. Git does not save file meta data, so when creating a new clone of mediawiki, all timestamps start with "now". This could be mitigated by using hashing of file contents instead of timestamps. Another workaround would have some kind of persistent clone because when running git-pull or git-checkout, file that are unchanged keep their timestamp. * [ ] ..

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 should invalidate 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`).

This is about all caches related to ResourceLoader: * minification cache. * any tracked timestamps (of on-disk filesere 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, or other objects). * definition summaries. * module versions (as included in the startup manifest).browser HTTP cache, and client-side localStorage cache. Goal to measure success: * localstorage cache (cache key should remain the same> When upgrading MediaWiki from one wmf-branch to the next, modules should invalidate cache. Only if the module content changed (e.g. scripts, styles and other included resources). Known issues that prevent this are listed below. These currently cause web clients to have to re-download modules that are effectively unchanged, but are needlessly being invalidated when upgrading a wiki to a newer wmf branch:problems are listed below. * [ ] File modules include `localBasePath` in their definition summaryuse timestamps that don't persist. With the way Wikimedia deploys MediaWiki right now, each upgrade involves a fresh clone with Git. As such, which includwhile Git only changes the absolute path to `$IP`imestamps on-disk when files changed between checkouts, which for wmf-production includes the mediawiki deployment tag (e.ga new clone will always have the current timestamp for each file created during the clone. * [ ] Modules with messages use localisation cache timestamp. `1.26wmf4`)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 track file timestampsinclude absolute paths in their definition summary. Git does not save file meta data, so when creating a new clone of mediawiki,(e.g. all timestamps start with "now".`localBasePath`, This could be mitigated by using hashing of file contents instead of timestamps.which is `$IP`, Another workaround would have some kind of persistent clone because when running git-pull or git-checkout, file that are unchanged keep their timestampwhich at Wikimedia is a directory that includes a MediaWiki branch names like `1.26wmf4`). * [ ] ..