mediawiki.api.edit

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

mediawiki.api.edit

Jeroen De Dauw-2
Hey,

Yesterday I released a new feature in the Maps extension that uses the
mediawiki.api.edit resource loader module.

I developed this against MediaWiki 1.31 (the latest LTS and minimum version
of MediaWiki required by Maps). Today I found out that things are broken on
MediaWiki 1.33.0. Apparently the mediawiki.api.edit resource loader module
got removed.

What is the deprecation policy for such modules? I was rather surprised
that a module with no sign of deprecation is gone 2 releases later, without
any form of fallback.

And more importantly, how can I now make my code work with both MW 1.31 and
1.33? I see that on MW master, the relevant JS file is now part of the
mediawiki.api module. I could include both modules, which would work fine
on MW 1.31, though on 1.33 I'd still have a reference to a module that does
not exist. And since my own module definition is in JSON (extension.json),
I can't even check which MW version I'm dealing with (unless there is some
special syntax for this). I'm not seeing a sane solution that I can use
here, so help is much appreciated.

Cheers

--
Jeroen De Dauw | www.EntropyWins.wtf <https://entropywins.wtf> |
www.Professional.Wiki <https://professional.wiki/>
Software Crafter | Entrepreneur | Speaker | Strategist | Contributor
to Wikimedia
and Open Source
~=[,,_,,]:3
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: mediawiki.api.edit

Andre Klapper-2
On Wed, 2019-09-25 at 05:44 +0200, Jeroen De Dauw wrote:
> Yesterday I released a new feature in the Maps extension that uses the
> mediawiki.api.edit resource loader module.
>
> I developed this against MediaWiki 1.31 (the latest LTS and minimum version
> of MediaWiki required by Maps). Today I found out that things are broken on
> MediaWiki 1.33.0. Apparently the mediawiki.api.edit resource loader module
> got removed.

https://phabricator.wikimedia.org/rMWecc812f06e7dff587b3f31dc18189adbf4616351
> What is the deprecation policy for such modules?

I'd assume https://www.mediawiki.org/wiki/Deprecation_policy#Removal
applies: "Code MUST emit hard deprecation notices for at least one major MediaWiki version before being removed."

https://phabricator.wikimedia.org/T196802#5435748 for specific info.

Cheers,
andre
--
Andre Klapper (he/him) | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: mediawiki.api.edit

Daniel Kinzler-3
> I'd assume https://www.mediawiki.org/wiki/Deprecation_policy#Removal
> applies: "Code MUST emit hard deprecation notices for at least one major MediaWiki version before being removed."

Formally, this policy only applies to PHP code. The Scope section says:
"This proposed policy applies to the PHP API of the MediaWiki core
(mediawiki/core.git) codebase. It explicitly does not apply to the api.php API,
client-side JavaScript, HTML output, or database schemas."

I don't know if we even have a policy for the removal of JS modules. It would
certainly be a good idea to have one, so we don't randomly break custom JS code...


--
Daniel Kinzler
Principal Software Engineer, Core Platform
Wikimedia Foundation

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: mediawiki.api.edit

Bartosz Dziewoński
In reply to this post by Jeroen De Dauw-2
I think the least inconvenient solution would be to leave your
dependency on 'mediawiki.api.edit' in extension.json unchanged, and
conditionally register that module as an "alias" for mediawiki.api if it
doesn't exist, using the ResourceLoaderRegisterModules hook.

You could even be super lazy and register it unconditionally in
extension.json, it seems that the module from core will take precedence
if it exists, but ResourceLoader will apparently log a warning for this.

--
Bartosz Dziewoński

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l