cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Gill <stevengil...@gmail.com>
Subject Re: [VOTE] Cordova-Plugin-Whitelist and Cordova-Plugin-Legacy-Whitelist Plugins Release (attempt 2)
Date Tue, 31 Mar 2015 21:42:34 GMT
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 <iclelland@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 <stevengill97@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 <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
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message