Yes, precisely. Is there an accepted way to call it, so I don't confuse
people every time I talk about it ?
Yuri, I am working on getting some concrete examples.
Mariya
On Mon, Feb 11, 2013 at 3:24 PM, Chad <innocentkiller(a)gmail.com> wrote:
I believe Mariya is talking about the internal APIs
available to
extensions,
(eg: User, Title, EditPage, so forth), not the public API.
Yay, acronyms!
-Chad
On Mon, Feb 11, 2013 at 8:14 AM, Yuri Astrakhan <yuriastrakhan(a)gmail.com>
wrote:
Mariya,
Could you be more specific? What types of changes caused extensions to
break? I might be mistaken but the vast majority of the API framework
classes have been established over 5 years ago, with very few breaking
changes since. Most changes were related to adding new functionality (new
actions, new query submodules, new parameters), but that shouldn't have
significantly affected extension development.
I do plan to introduce a few breaking changes (majority of the extensions
should not be affected) in 1.21, such as the introduction of versioning,
further modularization to allow pageset reuse, etc.
See
http://www.mediawiki.org/wiki/Requests_for_comment/API_Future
Please note that in a rare case some features might be purposefully
removed
due to the security or scalability issues.
--Yuri
On Mon, Feb 11, 2013 at 7:58 AM, Mariya Nedelcheva Miteva <
mariya.miteva(a)gmail.com> wrote:
> Hi all,
>
> I have been talking to many third-party yas part of my WMF internship in
> the last few weeks and one the main concerns they express is the lack of
> stability in the PHP classes MediaWiki exposes from version to version.
The
> frequent changes in what I would call the
PHP-API makes extentions
> developement and maintenance much more difficult with compatibility from
> version to version becoming a problem. Solving the problem would
probably
> result in the development of more extensions,
easier maintenance, less
> hacks to core and more users upgrading to the latest MediaWiki version.
I
> am sure WMF developers are facing similar
issues especially with
projects
> like WikiData going on.
>
> My question is: With the given technical heritage that MediaWiki
carries,
> is it possible to have a (relatively) stable
set of PHP classes defined,
> with a pledge not to change them in the next X releases or at least with
> some longer deprecation time? What would maintaining such a PHP-API
entail?
> How difficult is it given the vast number of
dependancies in MediaWiki
> code? Does it require restructuring a lot of the current core code? Do
you
think it
should be a definite goal for WMF?
Thank you.
Mariya
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l