(Sorry for late reply, I was traveling and only had scarce Internet connection.)
On Fri, 12 Apr 2013 11:21:27 +0200, Daniel Friesen daniel@nadir-seen-fire.com wrote:
This sounds like a really ugly and hacky way to handle this issue.
A little, sadly. But it will *work*, unlike what we have right now.
This is something that's mostly a WMF issue but this solution would involve all general updates being accompanied by a hack just for WMF.
It would be trivial to remove these five lines or so in release versions. (Assuming, of course, we do want to remove them, as they won't be causing any trouble.)
It also wouldn't scale well to extensions.
There is already a hook for this that extensions are free to use. (Although I don't know of any that does.)
I also have a felling that it would fall apart quickly if we make say 3 or more incompatible css changes within a month. We'd have pages with three different timestamps. And the conflicts would re-appear on some pages.
Yes, it wouldn't be pretty, but you're exaggerating. The latter changes would just have to be made more carefully. It would still be better than status quo.
It sounds more like an issue with how smart ResourceLoader is and our current concept of what should and shouldn't be purged.
(... wall of text ...)
But from the issue we're having with incompatible css and html we might be wrong about that. Rather than trying to keep the css up to date all the time perhaps it's actually correct to serve old css on pages with old html instead of serving the up to date css. Even if it means that pages will be a little inconsistent with modifications to the UI. Some pages with old stuff and others with new.
For that we would start including timestamps for all css. And we'd make it so that the old css stays around at those urls so that on old pages the old css is loaded. To do that we could increase the time the server caches timestamped css. (...)
This is all true. It also seems quite hard to implement - and thus unlikely to be implemented - both on the MW core side and on the WMF engineering side. If you want to, feel free to; but please don't block my practical - while slightly hacky - solutions in favor of vaporware. I'm trying to make the skins better *right now*, and what I'm proposing would make it way easier than it is right now, both for the code author and for the reviewers.
I could implement what I'm proposing even more hackily in every incompatible change, sure, but this would be much nicer.