ayg wrote:

That fix would require us to invalidate every single page cached in Squid. This is not acceptable. The only possible option is to not cache the site CSS/JS and have the client check for a 304 on every request. This is what we do for images -- I don't know if it would be worth it for site CSS/JS.

Any other implementation is fine, as long as the end result is the same (JS & CSS changes go live immediately).

Also, if it's a problem for Squid, then make the feature optional with a default value of "disabled" (e.g., $wgCssJsCacheUpdatesImmediate = false). Not all MediaWiki sites run Squid... we don't.

ayg wrote:

(In reply to comment #2)

Any other implementation is fine, as long as the end result is the same (JS &
CSS changes go live immediately).

Well, it's not clear if any solution other than the present one is desirable for Wikimedia, at least.

Also, if it's a problem for Squid, then make the feature optional with a
default value of "disabled" (e.g., $wgCssJsCacheUpdatesImmediate = false). Not
all MediaWiki sites run Squid... we don't.

That's a fair point, yeah.

This change might not have immediately value for Wikimedia (due to squid), but I can tell you, after running several MediaWiki installations for several years, this issue causes so much trouble. We release a change that relies on (say) MediaWiki:Common.js, and it breaks for everyone who hasn't hard-refreshed their browser. The alternative is never to use MediaWiki:Common.js... but it's such a convenient feature, if only it could be relied upon.

Versioning in the URLs as suggested would be an improvement over current refreshing practice, if not necessarily a complete solution for every page view ever (eg, if you load an old cached page it still references the old cached CSS).

Edit timestamp or revision id for the page might work; check that it can be done without extra DB queries.

wilson.jim.r wrote:

What about using a BagOStuff as a write-through cache for the greatest revision id on any *.css or *.js in the MediaWiki namespace? That way, sites employing memcache would avoid the DB hit.

Edit timestamp or revision id for the page might work; check that it can be
done without extra DB queries.

Do you mean, the article being viewed, or the *.css/*.jss "page"?

See also bug 8433.

This is fixed in ResourceLoader. Changes to MediaWiki:Vector.css take effect immediately after saving on my dev install, and should take effect within 5 minutes after saving for other users.