You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Steven Gill <st...@gmail.com> on 2015/03/27 00:46:05 UTC
[VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist
Plugins Release (attempt 2)
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
Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist
Plugins Release (attempt 2)
Posted by Mark Koudritsky <ka...@google.com>.
+1
* built and ran a hello world app on Nexus 7 and iOS simulator
Also pinned app-hello-world version to 3.8.0 in cordova-lib:
https://github.com/apache/cordova-lib/commit/c154d527a5b52a5b1fd139f437c83f455cf92e10
This should be changed back once we pin cordova-android version to 4.0.
On Tue, Mar 31, 2015 at 9:02 AM, Ian Clelland <ic...@chromium.org>
wrote:
> +1
>
> * Verified package contents against public repo at the correct tags
> * Verified checksums and signatures
> * Built and verified functionality on android (4.0.0-dev/0669edd) and ios
> (no functionality, no issues either)
>
> On Tue, Mar 31, 2015 at 1:10 AM, Steven Gill <st...@gmail.com>
> wrote:
>
> > I like the sound of both ideas.
> >
> > Marks idea to make the default hello world app not install whitelist
> until
> > android 4.0 (use 3.8.0 for app hello world)
> >
> > Ian, that looks like a good proposal. We are definitely overdo for
> > something to properly track versions. Users should get a warning when a
> > plugin doesn't get installed due to version issues.
> >
> > -Steve
> > On Mar 30, 2015 6:18 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
> >
> > > Mark - I like that idea as well.
> > >
> > > On Mon, Mar 30, 2015 at 6:33 PM, Ian Clelland <ic...@chromium.org>
> > > wrote:
> > >
> > > > On 30 Mar 2015 4:52 pm, "Mark Koudritsky" <ka...@google.com> wrote:
> > > > >
> > > > > Another quick option for now: we can pin hello-world version in
> > > > > cordova-lib's package.json to 3.8.0 which doesn't use the whitelist
> > > > > plugin. Later, when we release the tools pinned to cordova-android
> > 4.0
> > > > we
> > > > > will have to change the hello-world dep to "^3.9.0".
> > > >
> > > > That's a good idea.
> > > >
> > > > I'll validate the plug-ins and vote later tonight.
> > > >
> > > > Ian
> > > > > This way it's a minimal change to cordova-lib and we can go ahead
> > with
> > > > this
> > > > > vote.
> > > > >
> > > > > On Mon, Mar 30, 2015 at 3:49 PM, Ian Clelland <
> > iclelland@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 <
> > kamrik@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 <
> > > agrieve@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 <
> > > > stevengill97@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
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > >
> >
>
Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist
Plugins Release (attempt 2)
Posted by Ian Clelland <ic...@chromium.org>.
+1
* Verified package contents against public repo at the correct tags
* Verified checksums and signatures
* Built and verified functionality on android (4.0.0-dev/0669edd) and ios
(no functionality, no issues either)
On Tue, Mar 31, 2015 at 1:10 AM, Steven Gill <st...@gmail.com> wrote:
> I like the sound of both ideas.
>
> Marks idea to make the default hello world app not install whitelist until
> android 4.0 (use 3.8.0 for app hello world)
>
> Ian, that looks like a good proposal. We are definitely overdo for
> something to properly track versions. Users should get a warning when a
> plugin doesn't get installed due to version issues.
>
> -Steve
> On Mar 30, 2015 6:18 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
>
> > Mark - I like that idea as well.
> >
> > On Mon, Mar 30, 2015 at 6:33 PM, Ian Clelland <ic...@chromium.org>
> > wrote:
> >
> > > On 30 Mar 2015 4:52 pm, "Mark Koudritsky" <ka...@google.com> wrote:
> > > >
> > > > Another quick option for now: we can pin hello-world version in
> > > > cordova-lib's package.json to 3.8.0 which doesn't use the whitelist
> > > > plugin. Later, when we release the tools pinned to cordova-android
> 4.0
> > > we
> > > > will have to change the hello-world dep to "^3.9.0".
> > >
> > > That's a good idea.
> > >
> > > I'll validate the plug-ins and vote later tonight.
> > >
> > > Ian
> > > > This way it's a minimal change to cordova-lib and we can go ahead
> with
> > > this
> > > > vote.
> > > >
> > > > On Mon, Mar 30, 2015 at 3:49 PM, Ian Clelland <
> iclelland@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 <
> kamrik@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 <
> > agrieve@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 <
> > > stevengill97@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
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> >
>
Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist
Plugins Release (attempt 2)
Posted by Steven Gill <st...@gmail.com>.
I like the sound of both ideas.
Marks idea to make the default hello world app not install whitelist until
android 4.0 (use 3.8.0 for app hello world)
Ian, that looks like a good proposal. We are definitely overdo for
something to properly track versions. Users should get a warning when a
plugin doesn't get installed due to version issues.
-Steve
On Mar 30, 2015 6:18 PM, "Andrew Grieve" <ag...@chromium.org> wrote:
> Mark - I like that idea as well.
>
> On Mon, Mar 30, 2015 at 6:33 PM, Ian Clelland <ic...@chromium.org>
> wrote:
>
> > On 30 Mar 2015 4:52 pm, "Mark Koudritsky" <ka...@google.com> wrote:
> > >
> > > Another quick option for now: we can pin hello-world version in
> > > cordova-lib's package.json to 3.8.0 which doesn't use the whitelist
> > > plugin. Later, when we release the tools pinned to cordova-android 4.0
> > we
> > > will have to change the hello-world dep to "^3.9.0".
> >
> > That's a good idea.
> >
> > I'll validate the plug-ins and vote later tonight.
> >
> > Ian
> > > This way it's a minimal change to cordova-lib and we can go ahead with
> > this
> > > vote.
> > >
> > > On Mon, Mar 30, 2015 at 3:49 PM, Ian Clelland <ic...@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 <ka...@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 <
> agrieve@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 <
> > stevengill97@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
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
>
Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist
Plugins Release (attempt 2)
Posted by Andrew Grieve <ag...@chromium.org>.
Mark - I like that idea as well.
On Mon, Mar 30, 2015 at 6:33 PM, Ian Clelland <ic...@chromium.org>
wrote:
> On 30 Mar 2015 4:52 pm, "Mark Koudritsky" <ka...@google.com> wrote:
> >
> > Another quick option for now: we can pin hello-world version in
> > cordova-lib's package.json to 3.8.0 which doesn't use the whitelist
> > plugin. Later, when we release the tools pinned to cordova-android 4.0
> we
> > will have to change the hello-world dep to "^3.9.0".
>
> That's a good idea.
>
> I'll validate the plug-ins and vote later tonight.
>
> Ian
> > This way it's a minimal change to cordova-lib and we can go ahead with
> this
> > vote.
> >
> > On Mon, Mar 30, 2015 at 3:49 PM, Ian Clelland <ic...@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 <ka...@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 <agrieve@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 <
> stevengill97@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
> > > > > >
> > > > >
> > > >
> > >
>
Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist
Plugins Release (attempt 2)
Posted by Ian Clelland <ic...@chromium.org>.
On 30 Mar 2015 4:52 pm, "Mark Koudritsky" <ka...@google.com> wrote:
>
> Another quick option for now: we can pin hello-world version in
> cordova-lib's package.json to 3.8.0 which doesn't use the whitelist
> plugin. Later, when we release the tools pinned to cordova-android 4.0 we
> will have to change the hello-world dep to "^3.9.0".
That's a good idea.
I'll validate the plug-ins and vote later tonight.
Ian
> This way it's a minimal change to cordova-lib and we can go ahead with
this
> vote.
>
> On Mon, Mar 30, 2015 at 3:49 PM, Ian Clelland <ic...@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 <ka...@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 <ag...@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 <stevengill97@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
> > > > >
> > > >
> > >
> >
Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist
Plugins Release (attempt 2)
Posted by Mark Koudritsky <ka...@google.com>.
Another quick option for now: we can pin hello-world version in
cordova-lib's package.json to 3.8.0 which doesn't use the whitelist
plugin. Later, when we release the tools pinned to cordova-android 4.0 we
will have to change the hello-world dep to "^3.9.0".
This way it's a minimal change to cordova-lib and we can go ahead with this
vote.
On Mon, Mar 30, 2015 at 3:49 PM, Ian Clelland <ic...@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 <ka...@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 <ag...@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 <st...@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
> > > >
> > >
> >
>
Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist
Plugins Release (attempt 2)
Posted by Steven Gill <st...@gmail.com>.
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 <st...@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 <ic...@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 <st...@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 <ic...@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 <ka...@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 <
>> agrieve@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 <
>> stevengill97@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
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist
Plugins Release (attempt 2)
Posted by Steven Gill <st...@gmail.com>.
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 <ic...@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 <st...@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 <ic...@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 <ka...@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 <agrieve@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 <
> stevengill97@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
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist
Plugins Release (attempt 2)
Posted by Ian Clelland <ic...@chromium.org>.
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 <st...@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 <ic...@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 <ka...@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 <ag...@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 <stevengill97@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
> > > > >
> > > >
> > >
> >
>
Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist
Plugins Release (attempt 2)
Posted by Steven Gill <st...@gmail.com>.
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 <ic...@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 <ka...@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 <ag...@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 <st...@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
> > > >
> > >
> >
>
Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist
Plugins Release (attempt 2)
Posted by Ian Clelland <ic...@chromium.org>.
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 <ka...@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 <ag...@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 <st...@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
> > >
> >
>
Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist
Plugins Release (attempt 2)
Posted by Mark Koudritsky <ka...@google.com>.
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
On Fri, Mar 27, 2015 at 4:31 PM, Andrew Grieve <ag...@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 <st...@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
> >
>
Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist
Plugins Release (attempt 2)
Posted by Andrew Grieve <ag...@chromium.org>.
+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 <st...@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
>