You're right, --force does exist but the help for it says "forces copying source files from the plugin even if the same file already exists in the target directory" which is different conceptually from the force we want, in that we want to ignore engine restrictions.
We could overload --force to do that as well I suppose? On Thu, Jan 5, 2017 at 9:17 AM, Steven Gill <stevengil...@gmail.com> wrote: > I think `--force` does exist and work for plugin add > > On Wed, Jan 4, 2017 at 11:22 PM, Shazron <shaz...@gmail.com> wrote: > > > Forgot about that merged proposal. What's lacking here is I think, a way > > for the user to override the engine version enforcement (for whatever > > reason, buggy CLI or plugin.xml, or they know something we don't know), > > something like a --force-install or something to that effect. > > > > On Wed, Jan 4, 2017 at 11:13 PM, Joe Bowser <bows...@gmail.com> wrote: > > > > > First of all, do we even suggest that the plugins will work to begin > > with, > > > or do we just not prevent people from installing plugins and tell them > > that > > > it may or may not work or that it's not supported when it fails? I'm > > very > > > much with the latter, because while we don't test things we don't > > support, > > > some people are still using Ant for builds and some people are still > > > running the latest version of Cordova on Gingerbread, and while I think > > > people shouldn't be doing these things for very obvious reasons, I > don't > > > want to prevent them from doing it. > > > > > > Right now we only guarantee that the plugins released work on the most > > > recent version of Cordova that's released at any time. We only do > > > backwards-compatibility only because people ask for it (or complain > very > > > loudly when we break it). We don't do any testing of this past a > simple > > > spot check because we don't test plugins with prior versions of > > Cordova. I > > > think that we really need to figure out what we do support. We should > > > really stick to our six month deprecation policy on platform support > > unless > > > people want to step up and find the resources for all the CI work that > > > would be required. > > > > > > Basically, while I don't want to support earlier versions of Cordova, I > > > don't want to prevent people from using it either with an engine tag > > unless > > > there's some security thing or some blatantly obvious piece of > > > functionality that's required like in Camera. (Shouldn't > > > cordova-plugin-compat fix the compile problems on Android 4.1.1, or is > > this > > > a thing where you just bump the API level?) > > > > > > On Wed, Jan 4, 2017 at 8:21 AM, julio cesar sanchez < > > > jcesarmob...@gmail.com> > > > wrote: > > > > > > > I think we should start testing plugins with cordova-android 4.1.1 as > > is > > > > the lower required by Google to publish on Google play. If some > plugin > > > > doesn't compile then increase the engine version to next > > cordova-android. > > > > In example, camera plugin doesn't compile with cordova-android 4.1.1. > > > > > > > > For cordova-ios we should require at least 3.4.1 as is the version > that > > > > included the 64bit support, required by apple, not sure if they > > require a > > > > newer version for some other reason now. > > > > > > > > > > > > El 4 ene. 2017 2:52 p. m., "Filip Maj" <maj....@gmail.com> escribió: > > > > > > > > > Sounds like a good idea, but how to go about doing it? We probably > > > > > can't easily, for example, rule out older versions of iOS without > > > > > someone testing with an old Xcode version. > > > > > > > > > > On Tue, Jan 3, 2017 at 5:15 PM, Shazron <shaz...@gmail.com> wrote: > > > > > > Related: https://issues.apache.org/jira/browse/CB-6582 > > > > > > (almost 3 years old...) > > > > > > > > > > > > TLDR; we should update the engine tags, with as much granularity > as > > > > > > possible. > > > > > > > > > > > > I think we didn't do this because we don't actually know if it > > > > *doesn't* > > > > > > work on an older version (since of course we don't test the > current > > > > > version > > > > > > with older platform version) and didn't want to unnecessarily > > > restrict > > > > a > > > > > > user from installing it. > > > > > > > > > > > > We planned to pin core plugins to a cordova-lib version but we > > > decided > > > > to > > > > > > use engine tags in plugins: > > > > > > https://github.com/cordova/cordova-discuss/blob/master/ > proposals/ > > > > > pinningAndVersioning.md > > > > > > > > > > > > > > > > > > On Tue, Jan 3, 2017 at 12:26 PM, julio cesar sanchez < > > > > > jcesarmob...@gmail.com > > > > > >> wrote: > > > > > > > > > > > >> I have noticed that most of the plugins don't use the engine > tags > > or > > > > > have > > > > > >> them set to cordova 3.0.0 or 3.1.0 which are very old. > > > > > >> > > > > > >> As we drop support for old iOS/Android versions when updating > > > > > cordova-ios > > > > > >> and cordova-android, what is our policy for iOS/Android versions > > > > > support in > > > > > >> plugins? > > > > > >> > > > > > >> Right now people can use the plugins on very old versions of iOS > > or > > > > > Android > > > > > >> despite we don't support them on the platforms, as the plugins > > > engines > > > > > are > > > > > >> set to 3.0.0 or 3.1.0 on most of them. > > > > > >> > > > > > >> Should we start updating the engines to newer cordova versions? > or > > > > even > > > > > >> fine grain it to cordova-ios/cordova-android versions? > > > > > >> I have noticed that we even have engines for iOS versions using > > > > > apple-ios > > > > > >> on the engine tag > > > > > >> https://github.com/apache/cordova-plugin-wkwebview- > > > > > >> engine/blob/master/plugin.xml#L35 > > > > > >> (but not sure if this really does something as the plugin can be > > > > > >> installed/used in older iOS versions and what works or doesn't > > work > > > is > > > > > >> controlled in the code) > > > > > >> > > > > > >> Or just say that the old Android/iOS version is not supported by > > > > Cordova > > > > > >> anymore if someone complains about a plugin not working? > > > > > >> > > > > > > > > > > ------------------------------------------------------------ > > --------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > > > > > > > > > > > > > >
