The intention is that it allows plugins to specify that they require at
least a certain version of the native code for each platform. This would be
for things like added a new transport type to the bridge, as when we added
binary data transmission on iOS and Android a year or so ago. Any plugins
published that relied on it would specify at least that level of
cordova-android and cordova-ios, whichever releases the changes made it
into. It turns out that the native code is stable enough that this is
hardly ever relevant.
Answering your questions:
- The cordova-plugman version returning node's version sounds like a bug.
It should be Plugman's NPM version number so far as I know.
- Very few. Most of the significant changes happened several versions ago;
in most cases ">= 3.0" is sufficient.
- Build time (more precisely, plugin install time). There are currently no
constraints or checks for eg. what versions of Android a plugin supports.
- This is true even of the "cordova" one, which is actually the version
of the `cordova` CLI tool if memory serves.
Braden
On Tue, Feb 11, 2014 at 10:20 AM, Jonathan Bond-Caron <
[email protected]> wrote:
> I'm a bit confused about 'engines'
>
> To my surprise, "cordova-plugman" actually returns node's version:
>
> https://github.com/apache/cordova-plugman/blob/master/src/util/default-engines.js
>
> Some questions:
>
> - Should "cordova-plugman" be renamed to "node"?
>
> - Are there many plugins that depend on "version x" of
> cordova-android, cordova-ios, xcode, ...?
>
> - Are 'engines' meant be build time requirements vs. runtime
> (~webview) requirements?
>
>
>
> It all looks like build time, with the exception of "cordova" where
> cordova.js exec() is required by the plugins.
>
> J
>
>
