cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: [DISCUSS] Core Plugins and Android API 23
Date Fri, 15 Jan 2016 21:32:50 GMT
Sorry, wrong PR:
https://github.com/apache/cordova-plugin-inappbrowser/pull/136

On Fri, Jan 15, 2016 at 11:42 AM, Joe Bowser <bowserj@gmail.com> wrote:

> So, what does the timeline look like for a Plugins release.  I just did a
> major change in the InAppBrowser to fix tel: and sms: URIs so they do
> stuff, and it'd be cool if this also made if this got looked over and
> landed before the next release.
>
> https://github.com/apache/cordova-plugin-inappbrowser/pull/135
>
> On Thu, Jan 14, 2016 at 2:02 PM, Carlos Santana <csantana23@gmail.com>
> wrote:
>
>> I agree with final compromise, I also had a discussion with Nikhil during
>> holiday break offline and understood the situation, some 3rd party plugins
>> are not open source and customers/devs don't move as fast as we wish, but
>> having a CLI 6 with latest plugins being backwards compatible with lower
>> Android API is good base for developers to start upgrading.
>>
>>
>> On Thu, Jan 14, 2016 at 1:23 PM Steven Gill <stevengill97@gmail.com>
>> wrote:
>>
>> > 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