@Jdforrester (WMF) Is Edge considered "unknown"? Internally it continues the Internet Explorer version numbering (although it does make sense that most of the 30 versions in between the current version and Internet Explorer 11 wouldn't be supported).
Whatever the native code does and thinks its version is, it's not exposed to anything we write. :-)
I don't think a decision on intentional (rather than accidental/ad hoc) support for Edge has been made; "Current and previous version" is probably right, but I haven't discussed it with anyone else.
Microsoft has been advertising Edge as being an "evergreen" browser (meaning, it automatically updates, similar to Firefox and Chrome). If that is true, then it'd make sense to only support the last two stable versions.
Unfortunately, the data paints a different picture. Possibly tied to the fact that updates for Edge are still (like with IE) tied to OS-level updates for Windows.
In Feb 2016, Construct.net wrote that 2 months after Edge 13 came out, 26% of Edge users were still on Edge 12. (Based on data from StatCounter.com).
Looking at our own data, Edge 17 was released April 30, and analytics.wikimedia.org shows that almost three months later between July 15 - July 25, only 80% of Edge users used Edge 17, 14% used Edge 16, 3.8% Edge 15, and 2.8% Edge 14.
Extensions that tag releases
Tagged extensions probably follow the "master" policy. Moreover please do not rely on the compatibility policy information.
Currently, extensions can be "master" compatible ("the master branch of the extension is compatible with both current and older versions of MediaWiki" or "release branches" (where REL1_* branches correspond to the core branches of the same names).
What about extensions who use master as unstable development branch, and don't use release branches, but instead tag releases (and include core-compatibility information in extension.json)? Is it okay to say that these have a "tags" compatibility policy?
@Samwilson I think that if an extension maintainer uses tags, that in itself would be insufficient.
Of course, one is free to do whatever, but I don't see the benefit of standardising an endless number of differing policies. That's counter to the benefit of standardising. The cost of more policies goes beyond this page. It also affects actual site-admins in how likely it is they will understand, remember, and successfully execute each MW upgrade. Having more strategies definitely makes this harder.
It's fine, of course, for an extension repo to have tags, but for maximum impact on mediawiki.org and ease of upgrading for its users, it should also follow a standard policy ("master" or "rel").
For example, they could follow policy "rel" by updating the REL branches after each tag release to be in sync with the latest tag supported for that MediaWiki REL.
Or, even easier, follow policy "master", by using a "develop" branch for the unstable state, and periodically fast-forward "master" to the latest release tag.
In addition to causing confusion for site-admins, it would also ensure the ExtensionDistributor can still be used, given it only offers "master" and "rel". If an extension maintainer insists on using unstable master, tags only and no rel branches; their users would need to download the extension by other means - in which case the Compatibility page matters less.
Thanks Krinkle, that makes sense, and I agree that having fewer strategies is simpler to understand! :)
So it seems that tags for extensions do not really add any value (although, of course people can do whatever they like). Nor does adding a version number to extension.json or the extension template on the mediawiki.org page — because the rule (for the "rel" strategy) is that anything in a REL1_ branch is to be considered stable and released, regardless of whether it matches a tag (or has a version number).
Note that a lot of extensions use tags. It means look at the docu for compat info and it also means that using the extension distributor version may get you into trouble in a lot of cases. I agree with you that it is pointless to have a truly tagged extension in the WMF repo since they do not follow rel nor master as a strategy. Still this leaves us with the problem of how to document these extensions. I think it is best to have a policy label called docu indicating that you should look at the docu or alternatively not add a policy to the extension's page at all to actually force people to look at the compat info. Whatever you think is the better approach I guess.
I have read again what master (provides backports) and rel (does not provide backports) is supposed to mean. So tagged ones indeed fit better into master though not entirely. I have seen extensions labeled with master that deliberately break compat with older branches and do not provide backports. Mostly these ill-fated manifest 2 cases I believe to remember. Whatever. The wording of the compat policy needs to be improved I guess. In the end using corresponding branches for extensions to core should always work in an ideal world and exceptions are just the tagged extensions.
This was a jolly good conversation. Thanks for you input and all the interaction.
Sorry Kghbln; been a busy week. :)
Also, I'm not really sure what the answer is here (I'm confused). It seems that lots of people do tag and don't backport; that's certainly a common model in the PHP world outside MediaWiki. But if we don't support that (as in, we expect extension maintainers to do things differently) then we should probably do more to make it clear that there's no point in tagging extensions.
Another question I have is about testing (I know I should already know this but): if an extension is using the 'master' compatibility policy, there's no way to run tests against anything other than master MediaWiki is there? It's only the REL branches that are run against the corresponding other versions? So what's the best way to maintain backwards-compatibility of the master branch by getting its tests run against all current MediaWiki versions? It's possible to just backport, of course, even if not using the REL branches for releases, but it'd be cool if every patch could be run against older MW versions too, so it wouldn't need to be submitted four times.
No worries. I am no longer a grumpy goat. Is this what people refer to if they are talking about goatifying things? ;)
Well it is confusing since the compat tags "rel" and "master" do not improve predictability for extensions created and maintained by third party programmers. A tag means that the extension is compatible for the branches stated by the programmer but for master. If there is a bug for master the extension gets fixed and we get a new tag indicating the new set of branches the extension is meant to be compatible with.
My impression is, I may be wrong here, that most third party programmers who tag do not backport to the WMF specific branches nor do they intend to do so. Au contraire, the advise not the use the software provided by the extension distributor.
I guess testing is also organized differently by every third party programmer if they do automated testing at all. I know from SMW that it uses integration test heavily that are run parallel against a whole set of branches including master to see if he software passes or if issues need to be fixed for the next tagged release. I think that this is a pretty good approach but I have no clue how it fits into the compat policys, i.e. "rel" or "master".
Note that I am writing this as a wiki administrator since I am not a programmer. For me it will be nice to be able to predict which version can be run for what version of MediaWiki I have set up on my server. This was actually my hope for improvement to be enforced by the compatibility policy flag.
There is not interest to interact with me here. This is fine but please refrain from re-opening this thread. I conclude that the information provided by compatibility policy continues to be useless for most extensions.
Back to previous information.
@KghblnI don't agree with your most recent edit, I think we should advertise 1.27 as being compatible with PHP 7.1, since it currently is...I'm not sure how to address people installing/running older point releases, since they really shouldn't be :/
I was not 100% sure if I should do the edit for the very same reason you stated. In the end I preferred to look at the status when the first point release was published in combination with the remark below the table. I will revert since it is a wiki in the end. :)
Chrome on mobile
I see the browser support matrix for mobile hast two columns named "Chrome", one stating that version 48+, the other stating that version 43+ is supported. This either was mistyped and one column needs to be removed or it needs clarification what the distinction here is. @Jdlrobson, you've added this in https://www.mediawiki.org/w/index.php?title=Compatibility&diff=2416446&oldid=2415223, can you help with that?
PHP 7.2 Compatibility
Is PHP 7.2.0 compatible with MediaWiki? That is the current stable version of PHP (as of 1/1/2018).
Currently, MW1.30(current stable version) is not yet fully compatible with PHP 7.2. PHP will be issued a warning level error. If you disabled display_error in php.ini, there should not be any big problems.
Are we really supposed to support all versions of Safari since 5.1? It's a bit old.
@Amire80 Is there a specific web platform or browser feature you're finding absent in Safari 5.1? Since 2015, our support matrix is mainly based on feature detection, not browser detection. (See startup.js)
Not really. I was just surprised that we have something pretty old here.
I came here because of a question at Topic:U4chyrpe83knqy0y.
Is there MariaDB support? If yes, can it be added to the compatibility table? Thanks.
Now that the Wikimedia Foundation uses MariaDB on it's cluster, does the table need to be updated?
Is there a timeline for how far into the future MySQL support will continue? In other words, as the MariaDB and MySQL projects diverge is there a point in time that Mediawiki might be expected to drop official support for MySQL?
The Future of HHVM. It seems that HHVM is going to diverge from PHP to Hack; so perhaps it time to migrate to PHP 7.1 (as the only version that is going to be maintained long enough).
There's an ongoing discussion on wikitech-l about this.
Phabricator issue T176370 is tracking the proposal to migrate to PHP7.
Update A-grade browser support to reflect jQuery 3 on Opera
Updated the page to reflect the current state correctly again.
Following up a conversation with @Nikerabbit on CX SVG updates, we've identified, that out-of-the-box jQuery 3 is not supporting Opera 12.x any longer. We should update the matrix accordingly.
Go for it. :)
Process to change compatibility
I have at least one question based on the discussions related to HTML in phabricator: What is the process by which we decide to change MediaWiki's compatibility? Is it well-defined? Does it need calling out on this page?