Mailing List Archive

Backward compatibility guidelines
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.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Backward compatibility guidelines [ In reply to ]
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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Backward compatibility guidelines [ In reply to ]
On Mon, Nov 8, 2010 at 7:17 AM, Markus Krötzsch
<markus@semantic-mediawiki.org> wrote:
> 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.

Actually, what it says is:

"Extensions are branched along with MediaWiki, so trunk extensions
only have to support current trunk MediaWiki. However, per #General
principles, don't break support for old MediaWiki versions unless the
compatibility code is causing actual quantifiable problems, because
it's nice if users can get the extra features or bug fixes of trunk
extensions even if they're still using old MediaWiki. Some extensions'
maintainers deliberately maintain compatibility with old MediaWiki
versions, and their wishes should be respected in all cases."

The last sentence answers your question. The phrase "have to" in the
first sentence means they don't have to support old releases, but they
can if their maintainers want them to.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Backward compatibility guidelines [ In reply to ]
On Fri, Nov 5, 2010 at 5:23 PM, Aryeh Gregor
<Simetrical+wikilist@gmail.com> wrote:
> ...
I don't have anything useful to say, but I wanted to add state "+1"


Bryan

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Backward compatibility guidelines [ In reply to ]
2010/11/9 Aryeh Gregor <Simetrical+wikilist@gmail.com>:
> "Extensions are branched along with MediaWiki, so trunk extensions
> only have to support current trunk MediaWiki. However, per #General
> principles, don't break support for old MediaWiki versions unless the
> compatibility code is causing actual quantifiable problems, because
> it's nice if users can get the extra features or bug fixes of trunk
> extensions even if they're still using old MediaWiki. Some extensions'
> maintainers deliberately maintain compatibility with old MediaWiki
> versions, and their wishes should be respected in all cases."
>
Sounds good.

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Backward compatibility guidelines [ In reply to ]
On Wed, Nov 10, 2010 at 6:08 AM, Aryeh Gregor
<Simetrical+wikilist@gmail.com> wrote:
> "Extensions are branched along with MediaWiki, so trunk extensions
> only have to support current trunk MediaWiki. However, per #General
> principles, don't break support for old MediaWiki versions unless the
> compatibility code is causing actual quantifiable problems, because
> it's nice if users can get the extra features or bug fixes of trunk
> extensions even if they're still using old MediaWiki. Some extensions'
> maintainers deliberately maintain compatibility with old MediaWiki
> versions, and their wishes should be respected in all cases."

I support this wording.

--
Andrew Garrett
http://werdn.us/

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Backward compatibility guidelines [ In reply to ]
On 09/11/2010 19:08, Aryeh Gregor wrote:
> On Mon, Nov 8, 2010 at 7:17 AM, Markus Krötzsch
> <markus@semantic-mediawiki.org> wrote:
>> 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.
>
> Actually, what it says is:
>
> "Extensions are branched along with MediaWiki, so trunk extensions
> only have to support current trunk MediaWiki. However, per #General
> principles, don't break support for old MediaWiki versions unless the
> compatibility code is causing actual quantifiable problems, because
> it's nice if users can get the extra features or bug fixes of trunk
> extensions even if they're still using old MediaWiki. Some extensions'
> maintainers deliberately maintain compatibility with old MediaWiki
> versions, and their wishes should be respected in all cases."
>
> The last sentence answers your question. The phrase "have to" in the
> first sentence means they don't have to support old releases, but they
> can if their maintainers want them to.

Great, I overlooked this last part. +1 from me.

What remains of my email is the question how this "wish" is implemented
technically. Either one has to generally give up potentially problematic
updates on ./trunk/extensions, or there must be some record of each
extension's compatibility wish to determine which extensions an update
should be applied to.

-- Markus


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Backward compatibility guidelines [ In reply to ]
On Tue, Nov 9, 2010 at 2:08 PM, Aryeh Gregor
<Simetrical+wikilist@gmail.com> wrote:
> "Extensions are branched along with MediaWiki, so trunk extensions
> only have to support current trunk MediaWiki. However, per #General
> principles, don't break support for old MediaWiki versions unless the
> compatibility code is causing actual quantifiable problems, because
> it's nice if users can get the extra features or bug fixes of trunk
> extensions even if they're still using old MediaWiki. Some extensions'
> maintainers deliberately maintain compatibility with old MediaWiki
> versions, and their wishes should be respected in all cases."
>

Another +1

-Chad

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Backward compatibility guidelines [ In reply to ]
On Tue, Nov 9, 2010 at 4:52 PM, Roan Kattouw <roan.kattouw@gmail.com> wrote:
> Sounds good.

On Tue, Nov 9, 2010 at 7:48 PM, Andrew Garrett <agarrett@wikimedia.org> wrote:
> I support this wording.

On Wed, Nov 10, 2010 at 8:06 AM, Chad <innocentkiller@gmail.com> wrote:
> Another +1

I'm glad everyone likes this particular paragraph. Have you looked at
the rest of the page?

http://www.mediawiki.org/wiki/Backward_compatibility

Perhaps the link got lost in my usual wall of text.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Backward compatibility guidelines [ In reply to ]
On Wed, Nov 10, 2010 at 10:03 AM, Aryeh Gregor
<Simetrical+wikilist@gmail.com> wrote:
> I'm glad everyone likes this particular paragraph.  Have you looked at
> the rest of the page?
>

Yes, and I pretty much agree with everything you've said. Especially this:

"In an ideal world, anything that a third-party extension might call should
continue to work across versions. In practice this is impossible, since most
of our functions are public and we can't possibly keep all of them stable."

-Chad

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Backward compatibility guidelines [ In reply to ]
Bryan Tong Minh wrote:
> On Fri, Nov 5, 2010 at 5:23 PM, Aryeh Gregor wrote:
>> ...
> I don't have anything useful to say, but I wanted to add state "+1"
>
>
> Bryan

FWIW, that page has my support, too.



_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l