Make WordPress Core

Opened 16 years ago

Closed 16 years ago

#11450 closed defect (bug) (fixed)

Plugin compatibility info on upgrade page (improvement to r12407)

Reported by: denis-de-bernardy's profile Denis-de-Bernardy Owned by:
Milestone: 2.9 Priority: normal
Severity: major Version: 2.9
Component: General Keywords: has-patch
Focuses: Cc:

Description

r12407 lets one use the newly introduced compatibility array. There should be an additional case, before the other two, where the plugin explicitly declares itself as compatible with the new version of WP.

Attachments (2)

11450.diff (1.1 KB) - added by Denis-de-Bernardy 16 years ago.
11450.2.diff (1.2 KB) - added by Denis-de-Bernardy 16 years ago.
same patch, sticking to major versions

Download all attachments as: .zip

Change History (12)

#1 @Denis-de-Bernardy
16 years ago

I think we should also stick to using the major version of WP, e.g. WP 2.9 is equally good for WP 2.9, WP 2.9.1, etc. With rare exceptions, the chances that a plugin is compatible for WP X.Y but not WP X.Y.1 are about (should be about, anyway) zero.

#2 @dd32
16 years ago

  • Summary changed from improvement to r12407 to improvement to r12407 (Plugin compatibiliity info on upgrade page)

Please include descriptive titles in future.

#3 @Denis-de-Bernardy
16 years ago

Adding to this, some users declare a plugin as not working when it really is but they're running into bugs due to third party plugins -- or simply because they're not managing to use it, or it's not working at all. And there could potentially be cases where whatever pending issues there are got fixed.

We should expect the plugin's author to know better than the users of the plugin, if he took the trouble to declare his plugin as compatible.

#4 @TobiasBg
16 years ago

I agree, if a plugin author explictly says that a plugin compatible to WP X.Y, then it is. Otherwise, users with little knowledge (maybe they just couldn't find a setting, or expected something from the plugin which it can't do or doesn't provide) could maybe stop others from upgrading, which would be really stupid.
I also agree that sticking to major versions X.Y instead of X.Y.Z is enough. As far as I understand it from comments from core devs, .Z releases are for major bugfixes and security issues. And those usually don't break a plugin. And if they do, it probably was the plugin's fault anyway.

@Denis-de-Bernardy
16 years ago

same patch, sticking to major versions

#5 @Denis-de-Bernardy
16 years ago

  • Keywords has-patch added

two untested patches attached. sample plugin for testing:

http://wordpress.org/extend/plugins/sem-fancy-excerpt/

#6 @TobiasBg
16 years ago

  • Summary changed from improvement to r12407 (Plugin compatibiliity info on upgrade page) to Plugin compatibility info on upgrade page (improvement to r12407)

Of course Denis was 38 seconds faster than me with that reason :-)

In addition to your first patch, I suggest adding something like "from the community" to the string

'Compatibility with WordPress %1$s: %2$d%% (%3$d "works" votes out of %4$d total)'

so that the difference between "said so by the author" and "voted by the community" is more clear. Otherwise an average user doesn't know, where those votes come from.

But I guess, since strings were already frozen, it is too late for this patch anyway?

#7 @westi
16 years ago

I don't think we should put too much emphasis on the Tested field - in the long run I think that should go away anyway as it just causes needless svn updates of plugins by authors just to mark them as tested.

I would much rather we just focused on the compatibility information and encouraging the community to mark a plugin as compatible/not compatible so that we can benefit from the wisdom of the crowd.

If we are going to limit the compatibility checks to major versions then we should do that at the collection point or at least on api.wp.org before we return the info.

I think it would be better to keep the detailed specificity that we have at the moment and see how it pans out - hopefully going forward we can keep a tighter lid on the contents of point releases and then we will be able to change this to work on major versions.

For now I think we should get the feature out for people to use and garner some feedback.

#8 @markjaquith
16 years ago

As a plugin author, I'd be very unhappy if my Tested line were ignored completely.

#9 @ryan
16 years ago

I'd go with the first patch. On the api.wp.org side, we can return 2.9.1 (if latest WP release is 2.9.1) if the plugin has 2.9 set. If 2.9.2 introduces security updates that could break some plugins, for example, we'd have the option on api.wp.org of not auto bumping plugins that have 2.9.1 or earlier set.

#10 @ryan
16 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [12413]) Consult the tested field when checking plugin compatibility. Props Denis-de-Bernardy. fixes #11450

Note: See TracTickets for help on using tickets.