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 <innocentkil...@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 <yuriastrak...@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.mit...@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@lists.wikimedia.org > >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > _______________________________________________ > > Wikitech-l mailing list > > Wikitech-l@lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
