Plugin Compatibility Missing for 2.9, 2.9.1, etc.

[miqrogroove]

The versions being displayed by Plugin Compatibility are 2.8.4, 2.8.5, 2.8.6, and 2.9.2. That doesn't make sense. What happens to people who are looking for plugins to run on 2.9 and 2.9.1?

[mdawaffe]

Replying to miqrogroove:

The versions being displayed by Plugin Compatibility are 2.8.4, 2.8.5, 2.8.6, and 2.9.2. That doesn't make sense.

2.9, 2.9.1 and 2.9.2 are marked as "API equivalent". Which means that, supposedly, any plugin that works in one should work in all the others. 2.8.x are not marked as API equivalent (I don't know if they're actually equivalent or not), so they get listed separately.

What happens to people who are looking for plugins to run on 2.9 and 2.9.1?

They upgrade?

Kidding (half).

This arose from a misunderstanding about how the plugins directory should handle API equivalent versions. I'll separate them out.

[miqrogroove]

Replying to mdawaffe:

2.9, 2.9.1 and 2.9.2 are marked as "API equivalent".

This is not a good strategy for Plugin Compatibility. There are plugins that are version locked and will not activate if the version number changes for any reason.

[mdawaffe]

We now filter plugin author supplied data (in the form of the "tested up to" datum in the plugin header) through the equivalence class information.

So if a plugin author has "Tested Up To: 2.9.1" in the plugin header, api.wordpress.org and the plugins directory should say the plugin is "Tested Up To: 2.9.2" (... which is obviously a lie). This equivalence is meant to reduce author burden; authors don't have to edit their readme every time a minor release comes out.

The user submitted compatibility data (collected on the plugins directory site) is not aggregated by equivalence class: 2.9, 2.9.1, 2.9.2 are separate again.

Replying to miqrogroove:

This is not a good strategy for Plugin Compatibility. There are plugins that are version locked and will not activate if the version number changes for any reason.

Can you give some in-the-wild examples?

If this auto-equivalence-mapping is problematic, we could make it opt out: "Tested Up To: 2.9!" or something.

[miqrogroove]

Replying to mdawaffe:

Can you give some in-the-wild examples?

I only use about a dozen plugins myself. Half of them are self-authored. Among the others, the one I personally keep an eye on is qTranslate. Somewhere around plugin version 2.0 the author removed the deactivation code. Instead, in the current version, it stays activated and cripples the post editor. It also displays a message, "The qTranslate Editor has disabled itself because it hasn't been tested with your Wordpress version yet. This is done to prevent Wordpress from malfunctioning. You can reenable it by clicking here (may cause data loss! Use at own risk!). To remove this message permanently, please update qTranslate to the corresponding version." In other words, qTranslate is still never compatible with new (or old) WordPress point releases.

Displaying "Tested up to 2.9.2" for the wrong version in Extend was a disservice to users. I don't understand the logic of making it "opt out". The purpose of Plugin Compatibility and the Tested Up To header is to help identify these types of problems, not sweep them under the rug.

Here's an idea for authors who "don't have to edit their readme every time a minor release comes out." Add support for a Tested up to value called "branch". So, a plugin author could specify "2.9 branch" to indicate there are no problems anticipate with point releases, but the author has not yet checked 3.0 compatibility.

[Denis-de-Bernardy]

Itching to close as invalid/wontfix. What qTranslate does seems ludicrous. The author should be told that his plugin ought to ignore the minor version before disabling itself.

[miqrogroove]

Now versions 2.8.4 and 2.8.5 are missing. Ummm...