PHP as "library type"

[JDGrimes]

Some libraries will require higher versions of PHP, so maybe we do need to let modules specify the required PHP version. Otherwise, if we don't touch PHP at all, we may end up breaking a user's site by installing something that they can't run. The wpDataTables module is an example, since the wpDataTables plugin seems to require PHP 5.4. This is a requirement of the plugin itself, and not the module, but we can't really recommend using it on lower versions because we don't test the modules against them.

[JDGrimes]

Note that if we do this, we'll want to treat PHP as a library type with multiple different libraries, like regular PHP or HHVM, of that type.

[JDGrimes]

I don't think PHP should be a "library type", but I do think that we need to include it in the specification, under a separate section, like "supported environments" or something.

[JDGrimes]

On the other hand though, when a plugin requires a certain version of PHP, that is its business to ensure that it specifies that correctly. But if we build an extension to also require that version of PHP, it might still make sense to specify that, as the version required by the plugin could change (though usually we'd expect it to increase, not decrease).

[JDGrimes]

Worth noting that WordPress is currently in the process of handling PHP version requirements of plugins. Though that doesn't mean that we are off the hook as far as extensions go.

[JDGrimes]

All in all, I think that the principle that a dependent should support the same environment as its dependencies holds here. There is no compelling reason that this is needed at the moment, and offering the option would leave it open to abuse (that is, make it possible to require a different environment than the dependencies). So I am inclined to close this for now. There may be times when a feature cannot be built on older versions of environments, but for now those should be seen as special cases that can be given special handling in the dependent in question.

[JDGrimes]

I suppose one problem that might be encountered though is that a user might install and activate an extension without installing the dependency with the requirement, and thus not realizing that the requirement existed. However, that shouldn't happen once we start handling dependencies in WordPoints, because activating the dependent without the dependency would be blocked.