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
--
Niklas Laxström