On 05/11/2010 16:23, Aryeh Gregor wrote: 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

On Fri, Nov 5, 2010 at 5:23 PM, Aryeh Gregor <Simetrical+wikilist(a)gmail.com> wrote: I don't have anything useful to say, but I wanted to add state "+1" Bryan