Topic on Talk:Compatibility

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.