Talk:Recommended Revisions

Maintenance

This sounds like a great idea. The first thing that springs to mind is: how is this intended to be maintained? It seems like it's central and from the point of view of each MW version, but if it's going to be up to individual extension maintainers to update I wonder if it'd be better to do it from the point of view of each extension, and store it in the extension's page (or repo)? Although I guess if that were the case, then extension maintainers could just use the REL branches! So this is about not getting maintainers to change how they do anything, and is a system of documenting things? Sam Wilson 04:50, 6 September 2024 (UTC)

Sorry, I somehow missed this until now! I don't know if this question is still relevant to you at all, but: yes, this is intended to be centrally maintained, rather than up to each extension developer to report on the recommended revision for that extension. (Though that kind of feedback is of course very welcome.) Yaron Koren (talk) 12:48, 2 June 2025 (UTC)

I'll jump in on this section too, focusing on the "How" element.

How is this currently maintained? and how have you come up with the set of hashes in the YAML? (Which as there is no indication as to where they come from essentially seem random?) ·addshore· ^{talk to me!} 13:15, 2 June 2025 (UTC)

That's a fair question, and there should probably be more explanation on the page. This listing originated with the Canasta MediaWiki distribution, and it represented (and still represents) the best attempt of Canasta developers (including me) to find a good revision for each combination of extension/skin and MediaWiki version - which in most cases, is just the most recent revision in the appropriate "REL..." branch for that extension/skin when the list is compiled. (For many extensions and skins, though, especially among ones not maintained by the Wikimedia Foundation, more thought/research was required.) These lists are now used by the Springboard extension as well - and the hope is that, as more "eyeballs" fall on these lists, remaining issues will be addressed, in one way or another.

The basic philosophy here is that consistency is good - that, all things being equal, it's better to stick with a specific set of code that is known to generally work, rather than always using the latest code in the relevant branch, even if it's expected that all changes will be positive improvements - because you never know for sure what is happening in the code. That said, if there's an obvious bug fix that happened for that extension/skin, then it probably makes sense to update the listing. Until now, these have been mostly informal decisions; as "recommended revisions" takes on more usage (if indeed that happens), it will probably be necessary to make the decision-making process more formal. Yaron Koren (talk) 13:48, 2 June 2025 (UTC)

Nice, yeah, some details of that at the top of the page would be nice!

In my opinion, including extensions that already follow the REL_* pattern (and are forced to by the fact that) in the YAML file makes it harder to look at.

The fact that you already decided to include the wikidataid in the YAML file too, also then makes me wonder if the data all around is just better of being modelled there? (Will reply in the section below too touching on that)

Also looking at additional things (and steps):

• git submodule update: Seems redundant, if the extension has git submodules, and you are checking the extension out using git, you should be fetching / updating the submodules.
• database update: Really, this should be something that is detectable via MediaWiki again? Do we need a maint script for checking if there are pending DB updates? This is also already discoverable via extension.json.
• required extensions: This is also speced out in extension.json and should just be added there (I would also love to see suggested extensions)
• composer update: IMO should should either be encoded in extension.json OR we should agree that if a repository has non DEV only dependencies, that means they should be installed
• bundled: Again, this is already discoverable via git

So in summary, I think there is a lot of duplication with other sources of information already, and likely the better place to put most of those parts is in extension.json>

Having it maintained in both places will lead to either 1) it never being added to extension.json (the places it probably should be) and or 2) one or more of the locations being out of date and thus further adding to confusion.

That being said, im all for canista having its own list using for its builds.

It reminds me somewhat of wikiman and pacman that we made for wikibase.cloud https://github.com/wbstack/mediawiki/blob/main/pacman.yaml https://github.com/wbstack/mediawiki/blob/main/wikiman.yaml, and also in turn the various development environment guides such as MediaWiki-Docker/Extension/CodeMirror that again in my opinion should all be abstracted away and provided elsewhere (by the extensions themselves)

(Sorry for the long one, but very happy to keep chatting) ·addshore· ^{talk to me!} 15:37, 2 June 2025 (UTC)

By "including extensions that already follow the REL_* pattern ...", do you mean that such extensions (and skins) shouldn't be included in the file? If so, I guess that part wasn't clear either - these files are meant to also hold a "best practices" set of extensions and skins, which are both vetted and recommended.

The nice thing about specifying everything explicitly in the file is that you don't need to worry about outliers - extensions or skins where, for one reason or another, the rules aren't followed, and you can't get accurate information. (An extreme case is the Social Profile extension, which doesn't have an extension.json file, for reasons I don't understand.) That said, if it's possible already to consistently get information like "database update needed" and the required extensions for every relevant extension and skin, it's definitely worth considering switching to that approach. (Another upside to keeping everything in the file is that you don't then need to make 150 network calls to get the information, but that's already happening in Springboard anyway, for the Wikidata info, so maybe it's not a big deal.)

If you're talking about adding new information to extension.json, that sounds good, but it's not my domain. Yaron Koren (talk) 17:31, 2 June 2025 (UTC)

If you're talking about adding new information to extension.json, that sounds good, but it's not my domain.

I'd argue it should be your domain if you want to create Recommended revisions focused around the community of MediaWiki developers and extension maintainers.

Otherwise I would see this primarily as just some metadata around what canista does, no different to https://github.com/wbstack/mediawiki/blob/main/wikiman.yaml for example for wikibase.cloud.

It's just yet another copy of information in another format, which is fine, but this could all have far greater impacts on the MediaWiki communities.

We talked a lot in the past about coming up with sets of extensions for Wikibase that were recommended, and that's what ultimately gave birth to "Wikibase Suite", which again is another incarnation of the same problem (trying to know what should be installed with what, in what versions and what is generally recommended).

I think discovery of this across the board is important, and making it easy for that central discover place to maintain is also important.

I'd imagine that ultimately extensions are almost ranked, or split into tiers, I always like looking at https://landscape.cncf.io/ as a sort of starting point.

·addshore· ^{talk to me!} 09:36, 3 June 2025 (UTC)

To be clear, the target audience for this listing is not developers, but rather MediaWiki administrators (including wiki farm administrators) and package maintainers. I know that there are other such listings (although I didn't know about the Wikibase Cloud one), but hopefully this one, too, can be of use, for people looking for a good standard MediaWiki experience. It's already in use by two applications, Canasta and Springboard, and there are various Canasta-based packages that I assume will switch to it before too long, so I think we're in good shape as far as usage. I agree that it would be nice to get more information from extension.json, though. Yaron Koren (talk) 15:28, 3 June 2025 (UTC)

Right, but the source of information right now is essentially just your own judgement?

My argument is the source of this information should start with 1) the people developing and maintaining the extensions. And if you want to sprinkle your own custom advice on top, that would also in turn be great!

But yes, I think we are agreeing that extension.json sounds like a good place to try and move forward with providing this single source of truth that others can base this stuff on. And per the section below, we basically just need that be accessible and indexed somewhere.

I wouldn't be opposed to trying to help make a tool to do that at some point, but probably lacking time right now. ·addshore· ^{talk to me!} 10:38, 4 June 2025 (UTC)

To clarify, it's not just my own judgment - decisions about the inclusion of extensions and skins, and which specific revision to use, for the MW 1.39 and 1.43 lists, have been the work of a variety of Canasta developers. For the case of which extensions/skins to include, that has often been the result of explicit discussion (see here), while for the revision to use, if/when issues come up during usage of Canasta, such as mismatched versions of different extensions, that's a sign that something needs changing.

A truly decentralized approach like you're suggesting is tempting, but I think it wouldn't work, because (a) with 150+ extensions and 10+ skins, there's no way you can get every developer (or even a majority of the developers?) to do whatever additional work is required, and (b) the decisions about actual inclusion of extensions and skins presumably have to be done centrally, rather than letting any extension/skin developer decide which of their extensions/skins should/shouldn't be included.

The MW 1.44 list is a special case, because it was created wholly by another user, but I think it points the way to the future of these lists: as usage grows, with both the Springboard extension and various Canasta-based distributions, more users/developers will get involved with creating/modifying them, and the decision-making process will presumably have to become more formal. (With better results!) Yaron Koren (talk) 15:08, 4 June 2025 (UTC)

(a) with 150+ extensions and 10+ skins, there's no way you can get every developer (or even a majority of the developers?) to do whatever additional work is required,

This has been done before in the java, python, perl, ruby, nodejs, etc worlds. So yes, it's possible. It'll take some time, some communication and some love. But, yes, it's doable :-) —Ismael Olea (talk) 15:29, 4 June 2025 (UTC)

If you want to try your hand at herding 160 cats, feel free. :) I don't have the interest in it - and I'm pretty sure I don't have the authority to effect any needed technical changes, such as the addition of extension.json parameters. Yaron Koren (talk) 16:33, 4 June 2025 (UTC)

As I see, the comments from @Addshore applies both to developers as to admins. I still not very familiar with the mediawiki extensions ecosystem but I see deficiencies Springboard could help to fix and this will bring implications upstream (for extensions, an other artifacts, maintainers): to fully describe all the integration requirements in reusable metadata which, probably, should be hosted at upstream extension.json files to be collected and managed by Springboard. So, this would be two ways actions: to set up the Springboard infrastructure and to help/support/contribute upstream to extend the extension.json descriptions until they learn and be autonomous.

To me is a case analogous Flathub (Q43089335), which helped applications maintainers to publish excellent metadata to be used in this app store. —Ismael Olea (talk) 11:34, 4 June 2025 (UTC)

Repository location

Why have a 'repository' key? If it differs from what's recorded on the extension's page, then the page should be updated. Although I guess it makes it possible to track changes over time, e.g. an extension might move from GitHub to Gerrit, and this is wanting to point old versions to GitHub. But when that sort of move happens, repos are usually imported, so it'd be fine to point to the same commit on Gerrit. Sam Wilson 04:52, 6 September 2024 (UTC)

My apologies again. There are various reasons why it's good to be explicit with this sort of information, but one major reason is to avoid the possibility of malfeasance: a malicious user could change the repository URL on some extension to point to their own code repository, and until their bad edit is caught and undone, anyone using "recommended revisions" to download that extension will get the bad code, with untold consequences. Yaron Koren (talk) 13:01, 2 June 2025 (UTC)

REL branches

Instead of maintaining a list, I think it would be better if extensions had their REL1_XX branches set to whatever revision is best for that version. That way it is easier for people to download the right version directly from git or via Special:ExtensionDistributor. If anyone is a maintainer of an extension and wants their REL_XX branch set to something different then it is currently set to, send me a message and I'll look into changing it. Bawolff (talk) 06:50, 2 June 2025 (UTC)

If you're willing to fix up my extensions to get all the REL... branches to point to the right thing, that would be great for me! But I don't think it's feasible as a general solution for "recommended revisions". A good number of these extensions and skins are not even on Gerrit, and lack any REL.. branches - and presumably will never have them. Yaron Koren (talk) 13:03, 2 June 2025 (UTC)

The authors of such extensions can make REL branches. If the extension is hosted elsewhere, then it is even easier for authors to do that. As a standard I think it makes more sense then some wiki page anyone can edit. You can then manage the extension with standard tools like git. Bawolff (talk) 17:49, 2 June 2025 (UTC)

That's probably true, but unless you can convince all the dozens of relevant extension and skin developers to create and maintain REL branches for every MediaWiki version - now and in the future - it's probably not a workable solution, unfortunately! Yaron Koren (talk) 23:08, 2 June 2025 (UTC)

This all seems to be skirting around the fact that the "standard" way for extensions to express what core version they support is to use REL branches. That's what we expose to the world (even on your Cargo extension's page, Yaron, there's a download link in the infobox that uses ExtensionDistributor and therefore REL branches). The reason that doesn't work (and it doesn't, mostly) is I think a few things: it's unusual in the open source world; maintainers don't know to backport things; and we also expose a version number for extensions which then feels like it's the more proper signal of compatibility than some Git branch. I don't think the answer to all that is to ignore REL branches and invent a new system though. Sam Wilson 22:21, 3 June 2025 (UTC)

Mediawiki inventory

I think you are finding the same fault than me: the absence of an inventory of Mediawiki resources useful for tools, configuration control, etc. I called out for the specific case of Wikibase, but the problem is the same. I also would suggest to store the data on Wikidata or in https://Wikibase.world instead of using text. —Ismael Olea (talk) 11:35, 2 June 2025 (UTC)

Why would storing all this information in Wikidata or another Wikibase repository be better than text? Yaron Koren (talk) 13:04, 2 June 2025 (UTC)

"be better than text" should be obvious! :D But I'm glad to see you are using YAML ;) ·addshore· ^{talk to me!} 13:14, 2 June 2025 (UTC)

I may be missing something, because I have no idea why it would be better to have such information in a structured repository rather than in a text format like YAML! It just seems like it would be a ton more work to maintain. Yaron Koren (talk) 13:51, 2 June 2025 (UTC)

Arguably, a set of random YAML content on random wiki pages on mediawiki.org is an equally odd place.

I guess the more mediawiki way would be to embed this on each extension page in the infobox for example, pointers about what to install with what probably already exist on wikitext pages on mw.org.

I believe all extensions on mediawiki.org can or do already have a wikidata entry, such as https://www.wikidata.org/wiki/Q28845553, so that would be the wikidata way.

And the software developer way would be to just embed this info within the git repos somehow, or make it automatically discoverable (as @Bawolff suggested in another section above).

Ideally, as with many things around software development, deciding what works with what should be done as close to the software development lifecycle as possible. So extension.json files feel right. Potentially with wikidata.org (or some other list of git repositories) used as a lookup for said files. ·addshore· ^{talk to me!} 15:38, 2 June 2025 (UTC)

Using information from extension.json does indeed make sense, conceptually. Using information from Wikidata - info related to the handling of the code, that is, not just info like the extension's display name in French - seems to me like a very bad idea. In the best case, you would have to populate and maintain such data on 150 or so Wikidata items - not just one value per field, but one value per MW version per field; and that's assuming there's a relevant property for everything. In the worst case, there's a major security threat - similar to what I noted in one of my (very belated) responses above, if you were to get the code repository URL from Wikidata, a malicious user could get everyone to download their own malicious code instead. Yaron Koren (talk) 17:39, 2 June 2025 (UTC)

Sure Wikidata can be changed, and likely for that reason it doesn't make too much sense using it as the starting point of the journey. However you could map to the Qid from extension.json if there were additional data fields that could be useful to store and lookup from there.

Re extnesion.json, i think the fact it is versioned is indeed a + here, as it means attrbiutes can change per version of an extension. Maybe in 1.42 its recommended to install with extension X, but that isnt the case on version 1.43 etc. (This is a large pain point of the way information is currently laid out on mw.org for extension installation)

At which point, the index of all information is just a list of code repos, and ideally the top level extension.json in the main branch would indicate how the tags or branches of the repo should be traversed to find other versions? I imagine this is primarily either REL_* branches, or tagged versions for most extensions? ·addshore· ^{talk to me!} 09:40, 3 June 2025 (UTC)

extension.json feels weird to me, as its supposed to be the manifest for the current version of the extension. Bawolff (talk) 17:49, 2 June 2025 (UTC)

That's what's good about extension.json - no? It can show, for the current (to it) version of the code, the correct values for attributes like "database update needed". Yaron Koren (talk) 18:12, 2 June 2025 (UTC)

I agree, the fact that extension.json always reflects the current state of the extension at a given time is good. I think what we're missing is a way to look at it over time, for example to see what version of core or PHP should be used. I do think REL branches are a great source of confusion for developers who come from the outside world where tags/releases are how particular versions are declared as ready for use. Sam Wilson 22:26, 3 June 2025 (UTC)

+1 to making a tool for this (I mentioned it in a section above just now). Basically packagist but for mediawiki. (this is of course the point someone needs to make the argument to just use packagist) ;) ·addshore· ^{talk to me!} 10:39, 4 June 2025 (UTC)

I've been making that argument for ages! :-) But yeah, it's a good point about the release methodology of packages on Packagist — we'd do well to follow that I think. The fact that the WMF does release branches doesn't mean it's the best for everyone else. Sam Wilson 11:37, 4 June 2025 (UTC)

Or, maybe, we all should use packagist and then Springboard evolve to be the proper UI for it.

PS (because I guess there is not UI for packagist right now). —Ismael Olea (talk) 11:38, 4 June 2025 (UTC)