There seem to be two groups of extensions: those which are not really maintained, and those with active maintenance and development work. We are relatively strict keeping our new core code backwards compatible (BC). That compatibility does not come free, but who is it for? It is for people who are not following MediaWiki development and it is for letting unmaintained extensions to work for a few more years.
Having said that, I think BC is important and we should continue be as strict about it as we have been. The current practice seems to be: 1) keep the old interface available unless it makes no sense anymore 2) add @deprecated in X, warnings in X+2, removed in X+4 where X is the current development version, the numbers may wary a little 3) update all extensions in the svn to use the new interface (with exception, see rest of this message) 4) add warnings and remove in version stated in 2)
But I also think there is place for us core developers to help the other group of extensions. What are we doing for people who are actively developing and maintaining extensions, trying to keep up with the latest interfaces and best practices? Usually these extensions want to support multiple version of MediaWiki simultaneously. Think about the Semantic MediaWiki extensions and the Translate extension. I will now talk about two practices, which would in my opinion be helpful.
Instead of just updating the code of those extensions to the new interface directly, right now we have to add conditions like if ( foo ) { do_it_the_new_way() } else { do_it_the_old_way() }. or use more convoluted mechanisms. Without coordination different people make different solutions.
I propose that we adopt a practice of amending old releases with new interfaces, essentially moving the burden from extensions to the core code itself. This doesn't mean that the whole new code needs to be backported. Take the RequestContext interface for example. We could very well add methods of this kind to our classes in 1.17: public function getUser() { global $wgUser; return $wgUser; }
I think it doesn't make sense to go further back than the latest stable release, or maybe even just the branched release if going back to the stable release would be particularly hard to do. For example, depending how easy it is to add the interface to older versions, right now it might make sense to add the new interface(s) only to 1.18 and forward, and not 1.17. I think this is called forwards compatibility (FC). The idea is that users are not going to update to development versions or even major releases very fast, but they could do a minor update and keep enjoying latest versions of their favorite extensions.
Another idea is adding @since annotations to new methods and classes and other changes. It's not fun to check the history of every function and determine the date it was added, just to make sure you don't accidentally introduce breakage when someone installs your extension in an older MediaWiki. Right now, the practice of adding @since annotations is not consistently followed or enforced.
I would like for us to: 1) start enforcing @since annotations for new core code 2) encourage adding FC interfaces to previous branches where possible (and to also make releases out of those branches including the interfaces)
-Niklas