[wp-hackers] Facebook API and WordPress Plugin Development - Insight / Best Practice

[Mike Schinkel]

On Nov 15, 2012, at 2:03 AM, Ryan McCue <lists at rotorised.com> wrote:
> Mike Schinkel wrote:
>> Specifically let's say I build a plugin for distribution via wordpress.org and I decide to include Mark's library. Also Jeffrey Nolte builds a plugin and uses Mark's library too.  All is still good because Mark's library checks class_exists() before creating the class.
>> 
>> However, Mark has 3 pull requests and from reading those pull requests is seems like they have features that in some cases might be requirements for use. And those pull requests also modify the API. 
> 
> If they modify the API, they're breaking compatibility, simple as that.

That position allows for no improvements to a library's functionality, and that's just not realistic.  Libraries should be able to make backward compatible changes that in many cases are not forward compatible.

For example if two plugins need the same library but Plugin A uses Library v1.0 whereas Plugin B needs Library v1.1 then if Plugin A loads Library v1.0 first Plugin B is screwed because it cannot load Library v1.1 but if WordPress would allow both plugins to register the library they each need WordPress could choose to load v1.1 instead of v1.0. And the code to make all this work is pretty trivial.

> This is one of the things we discussed at #wpcs (which is where that
> ticket was born), and there's no good way to handle it. 

Doesn't what I just presented above not a good way to handle it?  If not, why not?

> The best we can do is say "a requires b version >= 0.2", and the plugins have to handle

> API backwards compatibility.

I don't follow "a requires b version >= 0.2"

> Namespaces would help, but would still be a pretty crappy way of
> handling it.

Agreed.

-Mike