Template talk:Extension/2022

Getting the links to packagist back?

The links are back. :)

@Samwilson: Great change you did to the template today. Will make things easier. However one thing that got lost on the way was the direct link to the packagist page. Will be cool to get this back again. [[kgh]] (talk) 22:52, 19 January 2022 (UTC)

@Kghbln: Oops sorry! Where are you seeing an error? Sam Wilson 23:39, 19 January 2022 (UTC)

@Kghbln: Ah, it was the manual link! Fixed now.

I think generally the composer = line can be removed from extension infoboxes now. Sam Wilson 00:14, 20 January 2022 (UTC)

Thanks for fixing. I was basically seeing this on all pages using the composer parameter. Yeah, for the extensions in Gerrit these can indeed be removed. Cheers [[kgh]] (talk) 10:27, 20 January 2022 (UTC)

It is also automatic for extensions in https://github.com/MWStake/nonwmf-extensions Sam Wilson 10:39, 20 January 2022 (UTC)

Ok, so I accidentally found an extension which does not work for some reason: Extension:Semantic_Scribunto. It is listed in this repo: https://github.com/MWStake/nonwmf-extensions/search?q=SemanticScribunto [[kgh]] (talk) 10:44, 20 January 2022 (UTC)

Same with https://github.com/MWStake/nonwmf-extensions/search?q=SemanticCompoundQueries Something is not working [[kgh]] (talk) 17:47, 20 January 2022 (UTC)

Not working for Extension:Semantic Extra Special Properties too. [[kgh]] (talk) 16:16, 27 January 2022 (UTC)

Categorization of extensions supporting Composer

Even if using a manual link to Composer the extension should be categorized in Category:Extensions supporting Composer rather than just being added to Category:Extensions_with_manual_Composer_name. The latter category is just a maintenance category. I understand that only extensions in Gerrit have the information added automatically. [[kgh]] (talk) 10:36, 20 January 2022 (UTC)

I changed the module to just show "Extensions supporting Composer" in both cases since I do not know how to get lua to print two categories. [[kgh]] (talk) 16:15, 27 January 2022 (UTC)

Supported MediaWiki version

The template defaults to using extjsonuploader data. That works well in most cases, but not for supported MediaWiki version, where the value in extension.json means the MediaWiki version required for the current (master) version of the extension, while the template field is supposed to mean the oldest supported MediaWiki version (for extensions using the release branch compatibility policy, at least). I wonder if leaving the field empty would be a better default. Tgr (WMF) (talk) 12:49, 10 April 2022 (UTC)

I think it would make sense to use the version information from extjsonuploader data only when the compatibility policy is set to master. Otherwise, the value should be specified manually. Ciencia Al Poder (talk) 17:20, 10 April 2022 (UTC)

The field is almost always meaningless; yes, there's a 10-year-old version of the extension that used to work with MediaWiki 1.12 but no-one is testing it and certainly no-one is supporting it. Maybe we should label the field "minimum MW required by development branch" and have a second field for "oldest currently supported branch" which can be set manually (but only to a non-obsolete version, i.e. minimum 1.35 right now)? Jdforrester (WMF) (talk) 13:21, 11 April 2022 (UTC)

Presumably it was tested 10 years ago when it was used with 1.12; shouldn't that be enough? For extensions following the release branch model, which get snapshotted biannually together with MediaWiki, being able to see how far those snapshots go back is a nice convenience. Someone using an old MediaWiki version presumably doesn't care about support, or doesn't have a choice.

(I can see how the "supported MediaWiki version" terminology could be misleading for something very old that the maintainer, if there's still one, won't entertain fixes for, but that's my mistake, the infobox doesn't use that wording.)

And I don't think using the field for "oldest MediaWiki version for which there is a compatible extension version" would crowd out more useful information - you are supposed to install the extension from the release branch matching your core version, so knowing what older core versions the extension's development branch or latest stable is compatible with seems quite useless.

For extensions using the master compatibility policy, I agree leaving the current behavior (using the extension.json field) makes more sense. Tgr (WMF) (talk) 21:30, 11 April 2022 (UTC)

If the field is entered manually, it's often used to say what's the latest MediaWiki version where it has been tested. For example, unmaintained extensions may have an old value there and not work with the latest MediaWiki versions, or only support LTS versions. Ciencia Al Poder (talk) 07:52, 12 April 2022 (UTC)

"Latest MediaWiki version the extension is known to work with" is certainly more useful information than any of the alternatives mentioned above. The value pulled from extension.json isn't really useful for that purpose, though. Tgr (WMF) (talk) 09:40, 12 April 2022 (UTC)

"Latest MediaWiki version the extension is known to work with" is certainly more useful information than any of the alternatives mentioned above.

If "known" we mean "tests pass", then for 99%+ of extensions that's just master. Jdforrester (WMF) (talk) 20:30, 12 April 2022 (UTC)

"Known" would mean "someone tested the extension with this relase". The use case here is that someone adds (via extension.json or directly) something like "<= 1.35.0" (which at the time actually means 1.35-138), then 1.39 is released, drops deprecated features, which breaks the extension – knowing that the extension doesn't work with the latest MediaWiki release would be useful for more users than whether it can be made to work with 1.27 (or at least I'd hope so). Tgr (WMF) (talk) 11:10, 13 April 2022 (UTC)

Then call it "last manually tested with"? Jdforrester (WMF) (talk) 19:21, 20 April 2022 (UTC)

Continuing this conversation with a new title. Proactive programming (talk) 14:33, 14 December 2022 (UTC)

(In Template talk:Extension/2022#h-Tested_with_MediaWiki-20221214144200) Tgr (WMF) (talk) 21:57, 14 December 2022 (UTC)

Add 'bundled since' parameter

Currently bundled extensions are documented like:

{{Bundled|1.38}}
{{Extension
|status          = stable
...
}}

that is the information that it's bundled is provided via a separate template (Template:Bundled).

The problem with this is that the extension infobox still contains a prominent Download extension link and the note about the extension being bundled on top of the page is very easy to miss (indeed MediaWiki users might be used to just searching the Download extension link in the infobox). So I think it would be better to set this information via a bundled parameter, i.e.

{{Extension
|status        = stable
|bundled since = 1.38
...
}}

This could still add the {{Bundled|1.38}} note as usual but it could also additionally show "Bundled since 1.38" right before the Download link in the infobox. push-f (talk) 06:51, 14 October 2022 (UTC)

I don't think it's necessary to add more notices about bundled extensions:

• There's no harm in downloading an already bundled extension.
• Even if bundled, you may want to download it again to receive further updates, like bug fixes that usually don't warrant a new MediaWiki release. Ciencia Al Poder (talk) 07:49, 14 October 2022 (UTC)

Tested with MediaWiki

People need to know if the extension has been tested with a mediawiki version. I generally go from LTS version to LTS version and I skip the in between versions. So I would want to know if the extension I used with mediawiki 1.35 will work in mediawiki 1.39.x LTS.

Unit Test Master:

  Unit Test File: myextension/Unit Test Table
  Newest MediaWiki Version: 1.39.x LTS
  Oldest MediaWiki Version: 1.35.x LTS

MediaWiki 1.39.x LTS Status: Tested / Not tested / Tested with issues / Broken MediaWiki 1.35.x LTS Status: Tested / Not tested / Tested with issues / Broken

I personally do not think that we need to do this for every single version. The LTS versions are enough. But my view on this might be due to the fact that I stick with LTS versions and I would expect extension developers to make sure that their extension works with LTS version before worrying about the in between versions. Proactive programming (talk) 14:42, 14 December 2022 (UTC)

I guess this only applies to extensions with compatibility of 'master', because those with 'rel' are saying that they are tested and do work with the MW versions that correspond to the release branches. I've always felt that extensions with 'rel' shouldn't have their own version numbers, because it just means that it's possible to end up with confusion (or, as is often the case, the version number is rarely updated).

But yeah, a table in the infobox would be good, listing which core versions are supported (either by which extension versions, or just the existence of a REL branch).

Some extensions choose to keep supporting older core versions, and it'd be good if they had a way to specify that clearly. Sam Wilson 02:56, 16 January 2023 (UTC)