On Tue, Nov 20, 2012 at 5:19 PM, James Forrester jforrester@wikimedia.orgwrote:
So, the new proposal:
There would be a "top level" outline policy - a small number of browsers are supported (i.e., WMF will keep spending money until they work):
- Desktop: Current and immediately-previous versions of Chrome, Firefox,
MSIE and Safari
- Tablet: Current versions of iOS/Safari; Current and immediately-previous
ones of Android
- Mobile: Current versions of iOS/Safari; Current and the five previous
ones of Android[*]
Anything not in this list may "happen to work" but WMF Engineering will not spend resources (read, developer time) on it. If a volunteer is willing to work like hell to make, say, the VisualEditor work in Opera we would try to support them by reviewing/accepting patches, but nothing more than that. It doesn't mean we would go out of our way to break previous browsers as they leave support, but we would not hold ourselves back from useful development solely because it might break browsers that we've actively decided not to support.
In supporting browsers, there are basically a few categories of 'stuff you might have to do for a particular browser':
* use of features whose presence can be detected * use of features whose presence cannot be detected * workaround of bugs whose presence can be detected * workaround of bugs whose presence cannot be detected
Presence of features and bugs may, or may not, match up with major version numbers of software releases, so it's actually kind of tough to use a matrix for declaring what we should support. :(
"Current and immediately-previous" releases are also really hard to match up between projects on fast release cycles (like Chrome and Firefox which are pushing out new "major versions" every couple months) and those where "major versions" only change a few times per decade, like IE.
Supporting Chrome 22 (23 - 1) and supporting IE 9 (10 - 1) are totally different animals with different usage profiles. Really nobody should be running Chrome 22 -- it probably means your computer's broken and not installing updates -- but IE 9's all over the place -- as is 8.
What a matrix is *really good* at though is two things: * telling us what portion of our audience uses certain browser versions, which gives us some information for prioritization if a compatibility problem arises * telling ourselves/our testers what they should test on to confirm that they work
Roughly speaking, stuff should work in every browser that would reasonably support it without browser bugs. In the presence of browser bugs, we can go anywhere from inventing workarounds to blacklisting particular versions, and depending on the importance of the feature, ubiquity of the software version, etc it may be totally reasonable to leave some things broken or blacklist a feature on some browser version.
Let's not be afraid to blacklist things, but a one-size-fits-all default policy is tough to determine.
-- brion