Talk:Compatibility

Jump to: navigation, search

About this board

Extensions that tag releases

8
Summary by Kghbln

Tagged extensions follow the "master" policy

Samwilson (talkcontribs)

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?

Krinkle (talkcontribs)

@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.

Samwilson (talkcontribs)

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).

Kghbln (talkcontribs)

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.

Kghbln (talkcontribs)

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.

Kghbln (talkcontribs)

This was a jolly good conversation. Thanks for you input and all the interaction.

Samwilson (talkcontribs)

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.

Kghbln (talkcontribs)

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.

Reply to "Extensions that tag releases"
Summary by Kghbln

Back to previous information.

Legoktm (talkcontribs)

@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 :/

Kghbln (talkcontribs)

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. :)

EddieGP (talkcontribs)
ChristianSirolli (talkcontribs)

Is PHP 7.2.0 compatible with MediaWiki? That is the current stable version of PHP (as of 1/1/2018).

星耀晨曦 (talkcontribs)

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.

Reply to "PHP 7.2 Compatibility"
Amire80 (talkcontribs)

Are we really supposed to support all versions of Safari since 5.1? It's a bit old.

Krinkle (talkcontribs)

@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)

Amire80 (talkcontribs)

Not really. I was just surprised that we have something pretty old here.

I came here because of a question at Topic:U4chyrpe83knqy0y.

Reply to "Safari 5.1+?"
Danny B. (talkcontribs)

Is there MariaDB support? If yes, can it be added to the compatibility table? Thanks.

GoodMagician (talkcontribs)

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?

Reply to "MariaDB support?"
Alex Mashin (talkcontribs)

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).

Legoktm (talkcontribs)

There's an ongoing discussion on wikitech-l about this.

GoodMagician (talkcontribs)
Reply to "HHVM"

Update A-grade browser support to reflect jQuery 3 on Opera

3
Summary by 2003:72:6D71:1900:F969:60C6:115F:73EF

Updated the page to reflect the current state correctly again.

Volker E. (WMF) (talkcontribs)
Kghbln (talkcontribs)

Go for it. :)

2003:72:6D71:1900:F969:60C6:115F:73EF (talkcontribs)

Fixed it.

Izno (talkcontribs)

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?

Reply to "Process to change compatibility"
Spiros71 (talkcontribs)

Perhaps update the php table for MW 1.29 php 7.1 compatibility?

Kghbln (talkcontribs)

Updated assuming that 1.29 now fully plays with 7.1. The related task is fully messed since it cheerfully mixes the issue for core with the issue for extension.