cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <csantan...@gmail.com>
Subject Re: [Android] 5.0.x release branch?
Date Wed, 23 Sep 2015 16:36:09 GMT
No need to major version change for the Plugins, the API of the didn't
change.
Web developer still uses the same JS API to use the plugin.

Yes I did some thinking around the plugin search website. I think is a good
topic for the F2F.
Now that IBM is using Cordova Plugin more heavily to package our mobile
SDKs using Cordova Plugins, I think is beneficial to expose more info about
the plugin including engine tags

I would not go and build our own backend and have our own registry with
cordova metadata.

I think the solution is to put the metadata of plugin.xml into
package.json. We can show fast results in main search, but then user can
drill into the plugin details, and we can have a view with more information
and allow the user to select a specific version like we have today in our
plugin website search using the cordova registry.

The website can fetch the package.json and it will have the information to
display to the user.

So what I think we need to do is document and automate the information from
plugin.xml including engine tags into the package.json.

Today we have some sort of duplicate information between the "cordova" and
"keywords", I think it would be a good time to clean it up and add an array
in cordova.engines



On Wed, Sep 23, 2015 at 12:19 PM Nikhil Khandelwal <nikhilkh@microsoft.com>
wrote:

> Merging threads. I was no aware of any security implications of using
> reflection - Perhaps if the reflection target can be controlled through
> external data. In any case, I understand your hesitation with use of
> reflection. I would love to have longer discussions on the F2F on what
> approaches we could use to make this easier for Cordova developers.
>
> Joe: Could you add the appropriate engine tags in any case? That's how
> Cordova currently handles versioning between plugins & platforms. Also,
> does this imply that the plugins should have a major version bump as it is
> a breaking change? Please create the 5.x branches and if you could submit a
> PR - I had other minor code review comments on the diffs below.
>
> Carlos: I understand in the extreme case it can be a fairly complicated
> implementation with lots of criteria to use to determine the ideal plugin
> that might work given a set of platforms. However, trying a couple of
> previous versions of the plugins might work 80% of the time and that might
> be good enough. This requires more thought as there are quite a few
> scenarios here.
>
> As for plugin search website helping you find the correct engine tags - I
> like the idea. But this might requires us maintaining a backend for plugin
> search as this is specified in plugin.xml (and not package.json - or did we
> finally move this?).
>
> Thanks,
> Nikhil
>
> -----Original Message-----
> From: Carlos Santana [mailto:csantana23@gmail.com]
> Sent: Tuesday, September 22, 2015 6:14 PM
> To: dev@cordova.apache.org
> Subject: Re: [Android] 5.0.x release branch?
>
> +1 we should always use the engine tag to mark the minimum compatible
> +version at least
>
> -1 for cordova CLI to automagically to install an older version. It will
> be a pain to get this implemented right, we would need to download all the
> package.json for multiple versions of the plugin and pick the lowest common
> denominator based on engine tags and remember that one plugin support
> multiple engine tags across different platform versions and CLI/plugman.
>
> This brings an interesting feature to implement In the plugin search
> website, to display the engine tags for a specific plugin version. Allowing
> a developer to search for a compatible plugin for their current app.
>
> - Carlos
> Sent from my iPhone
>
>
> -----Original Message-----
> From: Joe Bowser [mailto:bowserj@gmail.com]
> Sent: Tuesday, September 22, 2015 6:17 PM
> To: dev@cordova.apache.org
> Subject: Re: [Android] 5.0.x release branch?
>
> I'm completely against using reflection for this purpose.  Version codes
> were invented for a reason and we don't have any mechanism in place to unit
> test any Android code (or any other native code on any of the platforms).
>
> I will vote against any release that includes reflection for this purpose
> since reflection has only brought us security issues and extreme WebView
> breakage when used (Simon can tell you the tales of the HTC console.log
> reflection code.).  Reflection is a worst-case scenario tool like when a
> method in WebView marked as deprecated completely disappears, not something
> we should make a habit of using often.  If we open the door for this, we'll
> get reflection creeping elsewhere, like the Plugins API.
>
> Just say no to reflection.
>
>
> On Tue, Sep 22, 2015, 5:57 PM Nikhil Khandelwal <nikhilkh@microsoft.com>
> wrote:
>
> > Thanks, Joe for the detailed explanation. I understand why we've taken
> > this route. It's good that this is only a build failure. One of the
> > complaints we commonly hear from Cordova developers is that "I have a
> > cordova project with a certain version of the platform, I need to find
> > the plugin that will work with it". Our CLI always defaults to add the
> > latest released version of the plugin.
> >
> > After this breaking change, an existing cordova project with
> > cordova-android < 5.x, cannot build with the latest version of the
> > following plugins:
> >                 - camera
> >                - geolocation
> >                - contacts.
> > These are some of the most popular plugins in cordova plugin ecosystem
> [1].
> >
> > I propose that we should do our best to avoid disruptive breaking
> > changes here. Some ideas that come to mind:
> > - As Joe mentioned below - reflection. It has the downsides that Joe
> > mentioned. No one likes to write code like this it but results in
> > least grief for Cordova users. Some pain here for plugin developers
> > will simplify the experience for large number of corodva JS
> > developers. I know we are doing some of this in cordova-ios [2] and
> > would love to find ways on how to make this manageable and not super
> ugly.
> > - Add an  '<engine name="cordova-android" version=">=5.0.0" /> '  to
> > the plugins - failure happens at plugin add in this scenario.
> > Cordova-lib could be more intelligent to detect this error and resort
> > to using an older version of the plugin. The downside of this is that
> > these projects cannot use the latest and greatest of these plugins.
> >
> > Thanks,
> > Nikhil
> >
> > [1]
> > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcordov
> > a.apache.org%2fuse-the-force-luke%2fplugins%2f%3fsortBy%3dDownloads&da
> > ta=01%7c01%7cnikhilkh%40microsoft.com%7c5d1a100510734c0605f508d2c3b4b9
> > c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=7apFzmhrtn%2bKulHrNn46
> > kkRG%2bZp3KarDUTf2y0i7P5I%3d
> > [2]
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> > b.com%2fapache%2fcordova-plugin-camera%2fblob%2fmaster%2fsrc%2fios%2fC
> > DVCamera.m%23L44&data=01%7c01%7cnikhilkh%40microsoft.com%7c5d1a1005107
> > 34c0605f508d2c3b4b9c2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=CkH
> > zeZ9uQUfYPDdAGlO2PJ9xJz89sZI5bdMRSlQtrMo%3d
> >
> > Thanks,
> > Nikhil
> >
> >
> > -----Original Message-----
> > From: Joe Bowser [mailto:bowserj@gmail.com]
> > Sent: Monday, September 21, 2015 6:32 PM
> > To: dev@cordova.apache.org
> > Subject: Re: [Android] 5.0.x release branch?
> >
> > On Mon, Sep 21, 2015 at 5:43 PM Nikhil Khandelwal
> > <nikhilkh@microsoft.com>
> > wrote:
> >
> > > Can you explain why latest plugins will not be compatible with older
> > > versions of Cordova?
> >
> >
> > They won't be compatible because Cordova-Android compiles against API
> > 22, and these plugins will require API 23 so that they can detect
> > permissions and support Marshmellow.
> >
> >
> > > Can this be avoided by any means?
> >
> >
> > Only with a lot of Java reflection, and I'd rather not subject plugin
> > developers to that, or try to hide it under the hood in some awful
> > utility class that everyone will want to see die.  I'm very much a fan
> > of if statements because they work, and they're easy to read and
> > debug, unlike when bad things happen to things you reflect into.
> > Plugins that require API 23 will only work with Cordova-Android 5.0
> > and up.  This only impacts five of our core plugins, but any plugin
> > that requires permissions from the Android Manifest will have to be
> > updated.  If we can avoid using advanced language tricks to make the
> APKs compatible, we should do that.
> >
> > When you mean they would not be compatible - will it result in a build
> > or
> > > runtime failure?
> > >
> > >
> > This will be a build failure, since API 22 does not have these
> > permissions, nor does it have the code required for API 23.
> >
> >
> > > For marshmallow, what is the guidance that we need to issue to the
> > > larger Cordova plugin ecosystem? Joe you are ahead of the curve here
> > > compared to most other plugin developers - a blot post explaining
> > > what are known gotchas would be great. I really hope we can use our
> > > Cordova blog to communicate these changes actively to the plugin
> ecosystem.
> > > This mailing list only gets 400+ subscribers.
> > >
> > >
> > There will be a blog post once 5.0 is released.  We're not forcing
> > people to upgrade to 5.0, and we will be supporting the 4.x branch for
> > six months.  This does mean we're stuck supporting 3.x, 4.x and 5.x
> > for a brief window, but I have no control over when Marshmallow is
> > released, only whether we want to support it or not.  I think we do, but
> I could be wrong.
> >
> > At least this should be easier than the jump from 3.x to 4.x for most
> > people, but the alternative is that your plugin just doesn't work at
> > all on Marshmallow.  We need to at least give plugin developers this
> > option, since it'll roll out on all the Nexus devices in the next two
> > weeks, and we'll hear more about it.
> >
> >
> > > Can you re-base your cordova-android over the current master? It's
> > > hard to see a diff in the current form:
> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > > hu
> > > b.com%2fapache%2fcordova-android%2fcompare%2fmaster...infil00p%3asmo
> > > re
> > > s&data=01%7c01%7cnikhilkh%40microsoft.com%7cb451a04dccc64fabdb9608d2
> > > c2
> > > edb23c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=j0bxz39itXdtylHJ
> > > lv
> > > PYoJpZqXMhFjyTV35I9X5Yxzs%3d
> > >
> > >
> > I had to do a merge commit to get this to happen (boo), but it should
> > be mostly cleaned up now.  It seems some style cleanup creeped into
> > the most recent changes, but this should be a bit more readable.
> >
> >
> > > -Nikhil
> > >
> > > -----Original Message-----
> > > From: Joe Bowser [mailto:bowserj@gmail.com]
> > > Sent: Monday, September 21, 2015 2:14 PM
> > > To: dev <dev@cordova.apache.org>
> > > Subject: [Android] 5.0.x release branch?
> > >
> > > Hey
> > >
> > > In the next two weeks, Marshmallow will most likely getting released
> > > with the brand new Nexus 6P being released from Huawei.  Given that
> > > most of the Nexus devices will be getting this release, we should
> > > probably release the 5.0.x branch of Android soon, and get the new
> > plugins updated.
> > >
> > > It should be noted that the latest plugins will not be compatible
> > > with older versions of Cordova, which is a big deal.  This is due to
> > > the use of various compatibility checks to make sure they support
> > > Marshmallow and older versions of Android.
> > >
> > > So, if everyone can look over the smores branches of my GitHub
> > > before I create the 5.0.x branch and pull the changes into it, that
> > > would be
> > awesome.
> > >
> > >
> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > > hu
> > > b.com%2finfil00p%2fcordova-android%2ftree%2fsmores&data=01%7c01%7cni
> > > kh
> > > ilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f988bf86
> > > f1
> > > 41af91ab2d7cd011db47%7c1&sdata=%2fPKmL8KTsz5dnC3A75yMatXLQUnfK0Nv07%
> > > 2b
> > > ve4PVcCE%3d
> > >
> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > > hu
> > > b.com%2finfil00p%2fcordova-plugin-geolocation%2ftree%2fsmores&data=0
> > > 1%
> > > 7c01%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7
> > > c7
> > > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o6cLXM4f3kpUGCTlIv65ft8lKv
> > > 6p
> > > c5qbeY%2bdUxiP4bc%3d
> > >
> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > > hu
> > > b.com%2finfil00p%2fcordova-plugin-camera%2ftree%2fsmores&data=01%7c0
> > > 1%
> > > 7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72f9
> > > 88
> > > bf86f141af91ab2d7cd011db47%7c1&sdata=kNsHIv6Uw2ITcT1ABmNq1JCmPTSigCG
> > > Rb
> > > 4zWC8maWpE%3d
> > >
> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > > hu
> > > b.com%2finfil00p%2fcordova-plugin-contacts%2ftree%2fsmores&data=01%7
> > > c0
> > > 1%7cnikhilkh%40microsoft.com%7c1785194b1f82494fc2d908d2c2c99f36%7c72
> > > f9
> > > 88bf86f141af91ab2d7cd011db47%7c1&sdata=rZ%2f1AALPAtUwgSXyOL1uk1b0Y%2
> > > fe
> > > EmqLOdU%2fwua2TbLU%3d
> > >
> > > Work on audio is still outstanding, BUT for some reason Audio broke
> > > recently on both Lollipop and Marshmallow.  I didn't test it out on
> > > KitKat or Jellybean yet, but I'm wondering whether we should keep
> > > maintaining this or support the standard HTML5 audio and deal with
> > > the asset issue somehow (which isn't straight forward).
> > >
> > > I hopefully want to get a 5.0.x branch happening this week if we can.
> > >
> > > What do people think?
> > >
> > > Joe
> > >
> >
>

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