Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release (attempt 2)

[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
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>