Le 11/02/13 13:58, Mariya Nedelcheva Miteva a écrit : > 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. <snip>
That has been kind of a recurring issue over the last few years. VistaPrint have some nice and smart people, some of them are subscribed to our lists. Back in January 2012, "danb" posted a long email regarding the upgrade of their internal installation from 1.18 to 1.19. Do read it: http://www.gossamer-threads.com/lists/wiki/wikitech/267106 He list 9 examples of breakages VistaPrint encountered in MediaWiki extensions: 1) removal of global $action 2) removal of Xml::hidden() 3) broken Output::add() (had to migrate to resource loader) 4) various parser tag bugs 5) removal of MessageCache::addMessage() 6) removal of ts_makeSortable() (javascript) 7) brokage of WikiEditor adaptation 8) MediaWiki:common.js no more loading by default (security) 9) addHandler() javascript broken in IE8 Then the awesome Rob Lanphier (disclaimer: he is the director signing my contracts within the WMF) replied about us "breaking backwards compatibility" at http://www.gossamer-threads.com/lists/wiki/wikitech/267180 Since then, Rob has constantly stressed the MediaWiki core team to retain backward compatibility as much as possible. I think nowadays we most of the time leave behind a back compatibility call flagged with wfDeprecated() and remove the function after a few releases. I guess that would prevent lot of breakage in the future. The JavaScript issues are probably related to us not having the nice JS we have today nor the awesome QUnit test suite Krinkle bootstraped. I guess some of those issues would be catched nowadays. Same for IE8 compatibility, we have some virtual machines running Selenium tests against tons and tons of different browser. That raises our likeness to detect such issues. Anyway, what we could do is start writing PHP interfaces for our legacy code and have our classes defined as implementing them: http://php.net/manual/en/language.oop5.interfaces.php That would force us to actually document all of our legacy code and will present a nice list of what we expose to the public. cheers, -- Antoine "hashar" Musso _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
