The vote has now closed. The results are: Positive Binding Votes: 4
Steve Gill Andrew Grieve Ian Clelland Mark Koudritsky The vote has passed. I will publish these to dist and npm. On Tue, Mar 31, 2015 at 2:42 PM, Steven Gill <stevengil...@gmail.com> wrote: > 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 <iclell...@chromium.org> > 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 <stevengil...@gmail.com> >> 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 <iclell...@chromium.org> >> > 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 <kam...@google.com> >> > > 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 < >> agri...@chromium.org> >> > > > 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 < >> stevengil...@gmail.com >> > > >> > > > > 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 >> > > > > > >> > > > > >> > > > >> > > >> > >> > >