r62700 MediaWiki - Code Review archive

MW 1.14 is less than an year old, and there has only been one further release since then - I see no reason not to continue supporting it. From a personal point of view we are still using 1.14 at my company, and that won't be upgraded for at least 6 months as we are in the middle of a big Bugzilla upgrade, and SVN is next on the list after that. Therefore it is in my interests to keep this extension working on 1.14, and I see no real harm from the MW perspective in doing that.

I was unaware of the wfDeprecated() issue, so I agree that my solution was not appropriate for trunk, but what about the suggestion I maid in the comments to r62506:

   if ( class_exists( "MWTidy" ) )
      $text = MWTidy::tidy( $text );
   else
      $text = Parser::tidy( $text );

This would work in all versions and prevent this unnecessary breakage.

Another alternative would be for me to maintain a 1.14 compatibility branch, but that seems like a lot of extra work when a much simpler solution is available!

I maintain my position that you shouldn't be trying to run trunk extensions on a 1.14 install. This is the exact reason we branch, so we don't have to maintain back-compat hacks like this.

And is that position shared by other devs? Tim didn't seem to mind either way, so long as it was done properly.

Personally I would rather have this one fix in trunk than have to back-port all changes to the 1.14 branch.

Not all devs care, but I know I'm not alone in disliking back-compat hacks.

If it's absolutely necessary for you to run trunk Code Review on a 1.14 installation, I would suggest you maintain the hack locally, rather than putting it in SVN.

When I first said "hack", I wasn't referring to the change specifically, and calling it a "hack" is a bit unfair.

That said, I just don't like encouraging running mismatched core and extensions. It is not reliable, sometimes they will break and other times have b/c code. This could be avoided if we agreed on "b/c for X versions back only" or some other middle ground. So I guess HappyDog is right in that it is non-obvious.

The 1.16 release of this extension will support 1.16 MediaWiki and 1.15 (when MWTidy was added), which is OK for me. Though my bias as a dev is close version matching.

"Hack," "backward-compatibility check," the name's the same ;-)

I agree heavily on the mixing of extensions, it should not be done. Sometime's it's obvious like this (method does not exist). Sometime it might be less obvious. People who run mismatched installs like that open themselves up to that risk, so I certainly don't think we should be encouraging it. I'm not opposed to keeping back-compat around for awhile when an interface changes, and have (personally, this holds no weight) adopted a policy of:

• 1.14 - introduces a feature, adds the back-compat check
• 1.15 - back-compat is allowed to remain in place
• 1.16 - the back-compat is broken

And of course this increments with each version. We could tweak this, or come up with a new plan, but I do think it's important to finally nail down some policy on this.

I think that some kind of policy like that would be useful. Personally I would modify it to be something like "1 year or 2 releases, whichever is longer" but the important point is that users know what kind of support to expect, and developers know what it is acceptable to break.

I should also point out that two revisions that were committed today have both, in their own way, completely broken compatibility with anything prior to 1.16, which has not yet been released (and in the case of the former, it might even be 1.17 if the change is not back-ported!).

These are:

• r62907 - truncateHtml() was moved to language.php (i.e. moved from extension to core) and so CodeReview will no longer work on any earlier revision of MW.
• r62914 - svnImport was rewritten to use the Maintenance class, which was added in MW 1.16.