That is good rationale for that use case. Not sure how much our users would run into it. Do we have any plugins currently that we would want to install different files for older versions. Managing all of that code in a plugin will get ugly.
In NPM land, I think the answer would be to install an older version of the package (plugin in our case). I prefer this way. I personally think it should be up to the user to install older versions of plugins if the newer one doesn't support their platforms. As long as we use semver properly, this shouldn't be a big deal. We could add logic for us to auto grab older versions but I think it might be too much magic from the users perspective. Sidenote: Read a post about nativescript plugins today. ( https://github.com/NativeScript/NativeScript/issues/25). They are planning on using package.json to install plugins (no plugin.xml). Some neat ideas in there that we might want to adopt ourselves in the future. On Tue, Mar 31, 2015 at 10:26 AM, Ian Clelland <[email protected]> wrote: > My thinking was that some plugins are going to need to have two very > different designs, say for cordova-android 3.7.0 vs 4.0.0, or cordova-ios > 3.8.0 vs 4.0.0. In that case, you could do something like this; > > <platform name="ios"> > <version match=">=4.0.0"> > <!-- tags for the new version --> > </version> > <version match="<4.0.0"> > <!-- tags for the backwards-compatiblity version --> > </version> > </platform> > > which i don't think you could do with the <engine> tags -- with <engine> > either all of the platform files are installed, or none of them are. > > Another way to do this would be to allow multiple versions to be available > on the CPR or on npm, and have logic to decide the best version of the > plugin to install. (with the ability to successfully install nothing if > that's the right choice) > > On Tue, Mar 31, 2015 at 1:17 PM, Steven Gill <[email protected]> > wrote: > > > Ian, instead of adding a version tag in plugin.xml, why don't we use the > > engine tag in plugins package.json? > > > > Something like: > > > > { > > "engines" : { > > "cordova-android" : "4.0.0", > > "cordova-ios" : ">=3.0.0 <4.0" > > } > > } > > > > > > If the user doesn't have the specified platform versions installed, user > > gets a warning and plugin doesn't install. If no engine is specified, > > install away. > > > > Thoughts? > > > > On Mon, Mar 30, 2015 at 12:49 PM, Ian Clelland <[email protected]> > > wrote: > > > > > So this isn't a -1, unless we can't fix the problem in cordova-lib. And > > > it's okay, I think, to fix it in cordova-lib/master and release that as > > > well. Nothing is actually broken by publishing either app-hello-world > or > > > plugin-whitelist until we release a version of tools that is pinned to > > the > > > new hello-world. > > > > > > > > > On Mon, Mar 30, 2015 at 3:40 PM, Mark Koudritsky <[email protected]> > > > wrote: > > > > > > > Looks like this breaks on cordova-android 3.7.1 (currently latest > > > released) > > > > > > > > cordova-app-hello-world requires the whitelist plugin > > > > whitelist plugin depends on cordova-android 4.0 via the engine tag > > > > <engine name="cordova-android" version=">=4.0.0-dev" /> > > > > The resulting error message is > > > > Plugin doesn't support this project's cordova-android version. > > > > cordova-android: 3.7.1, failed version requirement: >=4.0.0-dev > > > > > > > > Simply removing the <engine> tag results in compile errors. (change > > > > in CustomConfigXmlParser.parse() signature). > > > > > > > > Any ideas on how to solve this would be appreciated. Ideas we came up > > > with > > > > in a quick discussion: > > > > > > > > 1. Add "ignore" attribute to the <engine> tag that would result in > > plugin > > > > being silently ignored for incompatible engines rather than going > down > > in > > > > flames. > > > > 2. Add either <version> child or "version" attribute to the > <platform> > > > tag > > > > in plugin.xml > > > > > > > > > > This is my favorite idea so far -- I think we could do something like > > this: > > > <plugin ... > > > > <platform name="android"> > > > <version match=">=4.0.0"> > > > <!-- tags --> > > > </version> > > > </platform> > > > </plugin> > > > > > > I think this is overdue, and we'll find it useful as we move from 3.x > to > > > 4.x on other platforms as well. We would allow multiple <version> tags > > > inside of each <platform>, and any tags outside of the <version> tags > are > > > the default if nothing matches. > > > > > > In this case, there won't be any tags outside of the <version> tag, so > > the > > > fallback for 3.x is to install nothing, but succeed. > > > > > > Ian > > > > > > > > > > > > > > On Fri, Mar 27, 2015 at 4:31 PM, Andrew Grieve <[email protected] > > > > > > wrote: > > > > > > > > > +1 > > > > > > > > > > * Tested that both plugins compile on Android > > > > > * Tested that the non-legacy plugin does what its supposed to on > > > Android > > > > > > > > > > On Thu, Mar 26, 2015 at 7:46 PM, Steven Gill < > [email protected] > > > > > > > > wrote: > > > > > > > > > > > Please review and vote on the releases of > cordova-plugin-whitelist > > > and > > > > > > cordova-plugin-legacy-whitelist plugins. > > > > > > > > > > > > Release issue: https://issues.apache.org/jira/browse/CB-8739 > > > > > > > > > > > > The plugins have been published to > > > > > > dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8739/ > > > > > > > > > > > > The packages were published from their corresponding git tags: > > > > > > cordova-plugin-whitelist: 1.0.0 > > > > > > (38f5a9fa2c)cordova-plugin-legacy-whitelist: 1.0.0 (1ce26eba64) > > > > > > > > > > > > Upon a successful vote I will upload the archives to dist/ and > > upload > > > > > > them to npm. > > > > > > > > > > > > Voting guidelines: > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md > > > > > > > > > > > > Voting will go on for a minimum of 48 hours. > > > > > > > > > > > > I vote +1: > > > > > > * Ran coho audit-license-headers over the relevant repos > > > > > > * Ran coho check-license to ensure all dependencies and > > > > > > subdependencies have Apache-compatible licenses > > > > > > > > > > > > > > > > > > > > >
