On 05/11/2010 16:23, Aryeh Gregor wrote: > We just had a discussion in #mediawiki about this commit: > > http://www.mediawiki.org/wiki/Special:Code/MediaWiki/76064 > > It removed wfLoadExtensionMessages() from dozens of extensions in > trunk. With trunk MediaWiki, this causes no problems, since the > function does nothing. But in older MediaWiki versions, it will cause > the extension to break. Yaron reported that he quickly got a > complaint from someone using one of his trunk extensions together with > MediaWiki 1.15. > > This kind of thing has come up before, e.g., the removal of IE5 > support from Monobook. My take on this is that the cost-benefit > analysis is very simple: > > * Cost to users of removing wfLoadExtensionMessages() from trunk > extensions: If the extension happened to work on some old MW version > (some do), the extension breaks. > * Benefit to users of removing wfLoadExtensionMessages() from trunk > extensions: Nothing. Extension works the same as before, no better or > worse. > > I think it's very clear that in cases like this, we should not remove > back-compat. If there's some benefit, then maybe -- for instance, if > the code is hard to maintain, that could outweigh back-compat > benefits. But this code isn't hard to maintain at all, it's one line > in each extension. If there's no cost, then sure -- for instance, if > the extension already only works on trunk for some other reason (maybe > a new feature was added that uses a trunk function), then no harm is > caused by removing the back-compat lines. > > But going out of your way to remove back-compat when that will hurt > some users and not ease development *quantifiably* does not make any > sense, and IMO no one should be doing that. ("Quantifiably" means > "I'm not going to bother adding new feature X if I have to maintain > back-compat while doing it", not "I think the code is uglier".) We > can disagree about how much work we need to go into to maintain > back-compat, but it's not *negative* -- putting work into removing > back-compat without clear gain does not make sense. > > I've created a page on mediawiki.org to set out some guidelines we can > consider:<http://www.mediawiki.org/wiki/Backward_compatibility>. I > think we should get something written down that we can agree on, since > this issue has come up more than once before and the same people tend > to repeat the same disagreements every time.
Thanks, Aryeh, for taking this up. I largely agree with your analysis, but I am not sure if it is possible to develop one set of guidelines that fits all (especially the role of extensions needs to be discussed here). But I agree that the particular wfLoadExtensionMessages() commit was a problematic issue (it surprised us just before a scheduled release, causing a bit of confusion and extra work). I think the core of the problem was that extensions usually assume that trunk/extensions is the directory for keeping *their* development trunk, not the directory where they keep a version that is compatible with (and only with) the current MW trunk. This assumption might be wrong, and I can imagine moving to another constant SVN directory if needed -- the MW maintainers surely should have the final say about what is in SVN and where. But right now I do not quite see what the proper process would be to develop an extension that is deliberately backwards compatible to a fixed MW version. The proposed backward compatibility page says that trunk extensions are only compatible with the current MW version. This implies that it is not possible to cleanly develop an extension that supports multiple MW versions in trunk at all: since branches are copies of an earlier state of the trunk, the proposed guidelines entail that branches are also compatible with only one version of MediaWiki. So where in SVN should an extension be kept that supports multiple versions of MW? This actually seemed to be the main controversy about the wfLoadExtensionMessages() commit: a different understanding about what is the actual development goal of extension code kept in trunk (as opposed to a different understanding on how to achieve this goal). I think it is safe to say that most extensions want to remain compatible with more than one MW version, but also that many small extensions are not affected enough to really care. First, they are not using so much MW features to be broken frequently; second, they often do not have file releases and can simply point users to direct SVN (branch) URLs for download; third, they are often feature-complete and very stable so that users typically will be more eager to upgrade MW than to upgrade the extension. With bigger extensions, the situation is quite the opposite, making it very impractical to work under a "one MW version only" development policy. The approach suggested by Aryeh aims at finding one strategy that is acceptable for all projects and people that are involved. I am not sure that such a single strategy exists, and I would be more happy if we could find a way that allows extension developers to keep control over their project's compatibility goal. (The new backward compatibility page has still a lot of merit for MW itself, of course; my concern here are just the extension projects.) The simplest way I can think of for doing this is to simply stop having automated commits that may break MW-compatibility on the extension directory. As of today, the overwhelming majority of work associated with changes in MW has to be done by extension developers manually anyway (e.g. there is no automated way of upgrading to Resource Loader). Automating the few cases where search-and-replace updates are possible seems to cause more costs than benefit (including the costs of agreeing on a unified backwards compatibility strategy). I think a much bigger help for extension developers would be to have a public page which logs MediaWiki changes that require extension developers to update their code. I am convinced that this best supports the goals of MW as a whole: at SMW we have always been committed to keep full compatibility to MW (even to MW trunk in our stable releases), and anything that makes it easier for us to keep our SVN directory consistent with our development requirements will only make us more efficient in delivering quality code. Cheers, Markus _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
