cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Gill <stevengil...@gmail.com>
Subject Re: [DISCUSS] Core Plugins and Android API 23
Date Thu, 14 Jan 2016 18:23:23 GMT
Awesome! I'll kick up a discuss thread

On Wed, Jan 13, 2016 at 5:42 PM, Richard Knoll <riknoll@microsoft.com>
wrote:

> Hey all,
>
> This change has been merged into the file, camera, geolocation, and
> contacts plugins (media did not actually require any change). I was able to
> build and run mobilespec on cordova-android 4.0.0 and cordova-android's
> master. We should probably push for a plugins release soon, since there are
> also some major bug fixes to the contacts and camera plugins that were
> recently pushed.
>
> Thanks,
> Richard
>
> -----Original Message-----
> From: Nikhil Khandelwal [mailto:nikhilkh@microsoft.com]
> Sent: Friday, January 8, 2016 12:12 PM
> To: dev@cordova.apache.org
> Subject: RE: [DISCUSS] Core Plugins and Android API 23
>
> We had a good discussion about this offline with Joe, Simon, Steve, Jesse,
> Parashu and Jason. We came to the following agreement:
> This is a temporary fix to the plugins which we need to take to ensure
> Cordova 5.x tools behavior of using the edge plugins does not break for our
> users. We will pursue the change for all the affected plugins. This will go
> out in the next PLUGINS release which will happen before the Cordova 6.0
> release. Since this a temporary fix, we aim to remove it in 6 months
> (giving reasonable time for our user base to move to Cordova 6.x+ which
> will have a better plugin version pinning mechanism).
>
> Thanks,
> Nikhil
>
> -----Original Message-----
> From: Simon MacDonald [mailto:simon.macdonald@gmail.com]
> Sent: Thursday, January 7, 2016 4:00 PM
> To: dev@cordova.apache.org
> Subject: Re: [DISCUSS] Core Plugins and Android API 23
>
> I'm going to play devils advocate a bit here:
>
>
> > There are valid reasons why many app developers might not be ready to
> > move to API level 23:
> >   1) They have an app which is stabilizing or in maintenance mode and
> > they don't want to risk destabilization by moving to a new major
> > Cordova version, Cordova Android platform, and Android API level.
> >
>
> If the developer is not ready to move to a new version of Cordova Android
> or the Android API would it not also follow that they shouldn't be changing
> their plugin versions?
>
>
> >   2) They are using a 3rd-party plugin which has not yet been updated
> > to request Android permissions as required by API level 23. There are
> > probably a lot of plugins affected, since access to any of the
> > following things on Android M requires runtime permission requests:
> > calendar, contacts, phone, camera, microphone, location, beacons,
> sensors, SMS, storage.
> >
>
> Right, so if the 3rd party plugin they are using doesn't support Android M
> they should either a) not upgrade or b) send a PR to the plugin maintainer
> so everyone can benefit.
>
>
> >   3) They might not have the capacity or ability to test their app on
> > devices running Android M. Because API 23 enables the new permissions
> > model only on Android M, it requires testing on that platform.
> >
> >
> Everyone has access to the Android emulator.
>
>
> > In any of the above cases, developers might still like to benefit from
> > some of the major bug fixes in those 5 popular core plugins mentioned
> > below. Or even if they weren't specifically looking for bug fixes, it
> > would be a much better experience if adding or updating one of those
> > plugins would just work, rather than failing on Android. The
> > explanation for the failure will not be obvious to many users, if they
> > overlooked the warning when installing the plugin or if they were
> > using another tool to add the plugin where the warning wasn't surfaced.
> >
>
>  Seems like you are describing a tooling problem here. If the tool doesn't
> surface the warning or allows the user to add a plugin that is incompatible
> with the version of Cordova Android that is being used really sounds like a
> bug in the tooling to me.
>
>
> > Of course developers should be encouraged to upgrade to the latest
> > most secure highest-quality version of Cordova. But the encouragement
> > does not need to be so forceful. This proposed change gives developers
> > more time to upgrade, and allows for more choice about when to upgrade
> > individual parts
> > (plugins) rather than limiting them to all-or-nothing.
>
>
>  I would argue that the developer has an infinite amount of time to
> upgrade. Nothing is forcing you to upgrade to the latest Cordova Android or
> Android API. They can continue to use the same version of Cordova Android
> and plugins that are currently working in their app. If the developer is
> using semver properly and we do our job right they shouldn't pick up
> breaking changes. For instance, if the API of a plugin changes we bump the
> major version of the plugin so users who setup their config.xml to use:
>
> <plugin name="cordova-plugin-camera" spec="^1.1.0" />
>
> will effectively prevent the user from picking up the breaking change in
> camera version 2.0.0.
>
> Simon Mac Donald
>
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhi.im%2fsimonmacdonald&data=01%7c01%7cnikhilkh%40microsoft.com%7c84fb6405edf74f47453208d317beb5e5%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=B8DuMuPF8aUU6xvIlpYTi3LJPs1HbENcHXS8JrHqEu0%3d
>  B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB
>   [  X  ܚX K  K[XZ[
>    ] ][  X  ܚX P  ܙ ݘK \ X  K ܙ B  ܈ Y  ] [ۘ[    [X[     K[XZ[
>    ] Z [    ܙ ݘK \ X  K ܙ B
>

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