Re: [DISCUSS] Cordova InAppBrowser Plugin Release

[julio cesar sanchez]

I’ve just sent two PRs, one is breaking as it removes the deprecated
platforms.
Another that removes deprecated/unneeded code for iOS.
If we merge the breaking one, we could also update the eslint config that
would also be breaking and we could bump the engines to require a newer
cordova-android.


El El vie, 3 nov 2023 a las 19:19, Niklas Merz 
escribió:

> Does anyone have any reason to delay a Cordova plugins release?
>
> Some merged fixes are due to be released for a long time. I will have a
> look at the open PRs and check dependency updates.
>
> Any outstanding patches to land?
> If not, I will start the release in the next days.
>

Re: [DISCUSS] cordova-plugin-geolocation Release

[julio cesar sanchez]

I’ve read the blog post and it mentions “The JavaScript of the plugin has
been upgraded to use ES6 features, such as `let` and `const`.”.
But the plugin engines still support cordova-android 6+.
Should we bump the engines to require latest cordova-android? Those new ES6
features won’t work on those old cordova-android versions.


El El sáb, 16 sept 2023 a las 14:22, Norman Breau 
escribió:

> Blog PR can be found at: https://github.com/apache/cordova-docs/pull/1335
>
> On 2023-09-14 11:57 p.m., Norman Breau wrote:
> > Does anyone have any reason to delay a cordova-plugin-geolocation
> > release?
> > Any outstanding patches to land?
> >
> >
> https://github.com/apache/cordova-plugin-geolocation/compare/rel/4.1.0...master
> >
> >
> > If not, I will start the release sometime over the weekend, assuming
> > that Hurricane Lee doesn't foil my plans.
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [DISCUSS] cordova-android 12.0.0 Release

[julio cesar sanchez]

I don’t think gradle 8 is a requirement for sdk 34, here it has
instructions for using sdk 34 in agp 7 and agp 4.2.0

https://developer.android.com/about/versions/14/setup-sdk


El El mar, 16 may 2023 a las 16:24, Norman Breau 
escribió:

> Personally I think we can wait on AGP 8/Gradle 8.
>
> It will only be required for API 34 support, and using AGP 7/Gradle 7
> doesn't
> completely block you from using Android Studio Flamingo (some things in
> AS doesn't work
> but you can still run/debug native code just fine).
>
> So we can introduce AGP 8 support on our next major when we preparing to
> target API 34.
>
> On 2023-05-16 11:20 a.m., julio cesar sanchez wrote:
> > I sent a PR for using gradle 8, but not sure if that’s something we want
> or
> > we prefer to wait as is a big breaking change and plugins with complex
> > gradle files might break if using features that were removed.
> >
> > El El mar, 16 may 2023 a las 5:02, Bryan Ellis 
> escribió:
> >
> >> Does anyone have any reason to delay a release for cordova-android?
> >>
> >> * cordova-android (12.0.0)
> >>
> >> https://github.com/apache/cordova-android/compare/rel/11.0.0...master
> >>
> >> Any additional outstanding changes to land?
> >>
> >> If not, I will start the release process shortly
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >> For additional commands, e-mail: dev-h...@cordova.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [DISCUSS] cordova-android 12.0.0 Release

[julio cesar sanchez]

I sent a PR for using gradle 8, but not sure if that’s something we want or
we prefer to wait as is a big breaking change and plugins with complex
gradle files might break if using features that were removed.

El El mar, 16 may 2023 a las 5:02, Bryan Ellis  escribió:

> Does anyone have any reason to delay a release for cordova-android?
>
> * cordova-android (12.0.0)
>
> https://github.com/apache/cordova-android/compare/rel/11.0.0...master
>
> Any additional outstanding changes to land?
>
> If not, I will start the release process shortly
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [DISCUSS] iOS Minimum Deployment Target

[julio cesar sanchez]

I don’t have any iOS 11 or 12 devices to test, so I would gladly go with
iOS 13.


There are no official stats from Apple since they group old iOS versions as
“other”, but according to data from January of 2022, iOS 13+14 were 93% on
iPhone and 88% on iPad.
Then according to data from May of 2022, iOS 14+15 were 96% on iPhone and
90% on iPad.
At the moment iOS 15+16 are 92% on iPhone and 87% on iPad.

But other than using a single icon (that is not clear if we would merge
that feature) or not having devices to test on those version, I don’t think
we have any technical reason for bumping the version.


El miércoles, 3 de mayo de 2023, Norman Breau 
escribió:

> Hello all,
>
> This is just to start a discussion about the iOS Deployment target for
> cordova-ios 7.x.
>
> Currently the deployment target is set to 11, and we have a pending
> feature for using a single source app icon[1] which
> requires iOS 12.
>
> There is a PR[2] already built to increase the minimum target to 12,
> however we should decide if that's what we should use,
> or if there any particular reason why we should go higher.
>
> Not to say that we should make our decisions purely because some
> third-party dependency but for example, Google Maps iOS sdk in their latest
> major release[3]
> requires iOS 13. So a prominent tech figure has decided that supporting
> iOS 12 is not worth it.
>
> References:
>
> [1] https://github.com/apache/cordova-ios/pull/1309
> [2] https://github.com/apache/cordova-ios/pull/1323
> [3] https://developers.google.com/maps/documentation/ios-sdk/rel
> ease-notes#2022-06-27
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [DISCUSS] cordova-ios patch release

[julio cesar sanchez]

This fix should also be included
https://github.com/apache/cordova-ios/pull/1255

And since it's going to be a minor release, we should probably include all
the features too.
I, as a user, would find it very confusing that issues that have been
marked as "fixed" years ago, are not included in the latest release.

Also, note that the "iOS 16.4 not being inspectable" thing, is only a
problem if using Xcode 14.3, I can inspect without problems when using
Xcode 14.1, even on iOS 16.4 and 16.5 beta. So users have a workaround.

El mié, 12 abr 2023 a las 9:13, Niklas Merz ()
escribió:

> Thank you all for the feedback.
>
> I agree that the small release should be 6.3.0 and I would prefer to
> keep this release small with the discussed changes cherry-picked:
>
> 1. feat: set webView.inspectable to true for Debug builds on iOS >= 16.4
> 2. (ios) fix: workaround for DisallowOverscroll on iOS 16
> 3. fix(node-18): ATS URL Parsing
>
> They are all merged now in master and 1 is already in the 6.2.x branch.
> If someone else want's to backport them in 6.2.x I would be happy for
> that.
>
> I would start the release then some time this week and try to get it out
> quickly. I can also start working on the next major next week (once I am
> back from vacation and have access to a Mac again). This way we can have
> look at more open PRs, version bumps and do some tests for the major.
>
> Thanks again for the help. I hope this is the best approach for the
> users.
>
> On April 11, 2023, "gmail.com"  wrote:
> > As a counterpoint I would propose just releasing what we have as
> > 7.0.0.
> > This would get all of our existing work into developer's hands and
> > reduce
> > the number of things that could be issues coming in from the field. I
> > think
> > this would be more agile and more consistent with the modern
> > philosophy of
> > continuous delivery.
> >
> > It could be ideal to release both minor and major release versions but
> > I
> > think this would be overkill.
> >
> > Considering that it has been a couple years or so since the last major
> > cordova-ios release, and its major version number is a few behind
> > Cordova
> > itself, I don't see any potential issue with an extra major release.
> >
> > Unfortunately I don't have much time to work on making any release at
> > this
> > point. Leaving now to best judgement of everyone else. Thanks to
> > everyone
> > actively working on the updates!
> >
> >
> >
> > On Tue, Apr 11, 2023, 1:21 PM Darryl Pogue 
> > wrote:
> >
> > > On Tue, Apr 11, 2023 at 10:08 AM Norman Breau
> > 
> > > wrote:
> > > >
> > > > I also want to point out (as we ran into issues cherry-picking and
> > > > testing locally against our apps)
> > > > that dpogue's PR for NodeJS 18 support won't be cherry-picked
> > easily as
> > > > the function
> > > > being changed has been renamed at
> > > >
> > > https://github.com/apache/cordova-
> > ios/commit/21983197042908dff4cd49b00728b0c1d6703322
> > >
> > > The function name changed, but the implementation didn't, so
> > > backporting it manually shouldn't be an issue.
> > >
> > > If the PR gets accepted to master, I'm happy to do the backport to
> > 6.x.
> > >
> > > > So it might be easier to cut off NodeJS 18 support off in
> > > > cordova-ios@6.x (We have never claimed support for it anyway)
> > > > and officially support NodeJS starting in cordova-ios@7
> > >
> > > My concern here is just that node 18 is already LTS, and it feels
> > like
> > > we'd be under increased pressure to get 7.0.0 out the door just to
> > fix
> > > this particular bug.
> > >
> > > Which is to say, I'm +1 on including both of the fixes in a 6.x
> > > release in the near future.
> > >
> > > ~Darryl
> > >
> > >
> > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> > >
>

Re: [DISCUSS] cordova-ios patch release

[julio cesar sanchez]

Can’t we do a major release?
Last release was over two years ago and I think we have a lot more fixes
and features than just the inspector fix, that would benefit users.

If not, it should be a minor release, not a patch release, since the
inspector fix is actually a feature.



El martes, 11 de abril de 2023, Niklas Merz 
escribió:

> Does anyone have any reason to delay a path release with iOS and NodeJS
> related fixes release?
> Any outstanding patches to land?
>
> If not, I will start the in the upcoming days.
>
> I would merge this PR [1] and use the 6.2.x [2] branch with the WebView
> [3] inspect fix.
>
> [1] https://github.com/apache/cordova-ios/pull/1302
> [2] https://github.com/apache/cordova-ios/tree/6.2.x
> [3] https://github.com/apache/cordova-ios/pull/1300
>

Re: Testing a new Plugin "Module" authoring method

[julio cesar sanchez]

I’ve seen this error pop up sometimes that seems to indicate that it’s not
possible, but not always, so might depend on how the aar is configured to
be used, glad to know it works for you.


> Direct local .aar file dependencies are not supported when building an AAR.
> The resulting AAR would be broken because the classes and Android resources 
> from any local .aar file dependencies would not be packaged in the resulting 
> AAR. Previous versions of the Android Gradle Plugin produce broken AARs in 
> this case too (despite not throwing this error).

About the SDKs that don’t work in modules, it’s not the SDK by itself, but
gradle plugins it might require to run, fabric is the one that comes to
mind, but I think it’s now part of some firebase project, don’t know which
one.


El jueves, 30 de marzo de 2023, Norman Breau 
escribió:

> Modules can bundle AARs and native libraries however there will be a
> conflict if you have multiple modules bundling the same libraries.
>
> Internally at my workplace we handle this by wrapping the native library
> (either native C++ or AAR/xcframework) around a plugin whose
> sole purpose is to provide the library, which multiple modules can use the
>  directive to import the plugin. This ensures that a single
> copy of the library is present for the application.
>
> Some examples:
> https://github.com/totalpaveinc/cordova-plugin-libcxx
> https://github.com/totalpaveinc/cordova-plugin-libsqlite (depends on
> libcxx)
> https://github.com/totalpaveinc/cordova-plugin-sqlite (depends on
> libsqlite)
>
> Where sqlite is a cordova plugin API into libsqlite, which contains the
> native SQLite C library, with additional C++ addons, making it depend on
> libcxx for android.
> We have another internal/private plugin that also depends on libsqlite and
> libcxx and it's cordova plugin declares the dependency so that the library
> wrappers
> are present at the application level.
>
> I believe this is only an issue if you bundle the libraries yourself as
> well. If you use Gradle to manage dependency artifacts, I believe those are
> all resolved at build time,
> assuming that you don't have two modules requiring on incompatible
> versions. (e.g. Plugin A wants X:1.0.0 where Plugin B wants X:2.0.0).
>
> If you know of any specific libraries that **has** to be bundled at the
> application level, would be interesting to know, but in those cases I think
> the existing  directive
> could be used to support that kind of use case.
>
> On 2023-03-30 11:57 a.m., julio cesar sanchez wrote:
>
>> I had similar thoughts in the past, but never had time to implement it
>> myself.
>>
>> For reference, Joe already tried to convert the Android part of
>> InAppBrowser plugin into a library project back in 2018
>>
>> https://github.com/apache/cordova-plugin-inappbrowser/pull/242
>>
>> Modules have some problems too, like not being able to bundle aar
>> libraries, and some native SDKs can’t be used in modules.
>>
>>
>>
>> El jueves, 30 de marzo de 2023, Norman Breau 
>> escribió:
>>
>> Hi all,
>>>
>>> I just wanted to announce that I've been experimenting with a different
>>> way of authoring Cordova plugins.
>>> I don't really have anything to show right now, but looking to get some
>>> abstract high-level feedback based on the idea.
>>>
>>> This is more or less a preliminary start of a discussion so that I can
>>> get
>>> some early feedback. The plan is to come back some time later with
>>> a more official specification document and usable PoCs for both Android &
>>> iOS platforms.
>>>
>>> Privately I've been experimenting with a more closer "native" method
>>> which
>>> I feel like solves several issues
>>> with the way that cordova plugins are traditionally authored.
>>>
>>> First I'll explain briefly the pains of authoring cordova plugins, and
>>> then I'll explain a high level idea that will likely solve the problems.
>>>
>>> Currently the plugins are authored by having a set of arbitrary source
>>> files as defined by the  /  directives,
>>> which also declares where these files should be copied to into the
>>> cordova
>>> native app project. Additionally, if the plugin requires
>>> changing resource files or adding additional configurations, they must
>>> make use of several directives which may include:
>>>
>>> - config-file
>>> - edit-config
>>> - resource-file
>>> - lib-file
>>> - framework
>>> - source-file / header-file
>>> - asset
>>

Re: Testing a new Plugin "Module" authoring method

[julio cesar sanchez]

I had similar thoughts in the past, but never had time to implement it
myself.

For reference, Joe already tried to convert the Android part of
InAppBrowser plugin into a library project back in 2018

https://github.com/apache/cordova-plugin-inappbrowser/pull/242

Modules have some problems too, like not being able to bundle aar
libraries, and some native SDKs can’t be used in modules.



El jueves, 30 de marzo de 2023, Norman Breau 
escribió:

> Hi all,
>
> I just wanted to announce that I've been experimenting with a different
> way of authoring Cordova plugins.
> I don't really have anything to show right now, but looking to get some
> abstract high-level feedback based on the idea.
>
> This is more or less a preliminary start of a discussion so that I can get
> some early feedback. The plan is to come back some time later with
> a more official specification document and usable PoCs for both Android &
> iOS platforms.
>
> Privately I've been experimenting with a more closer "native" method which
> I feel like solves several issues
> with the way that cordova plugins are traditionally authored.
>
> First I'll explain briefly the pains of authoring cordova plugins, and
> then I'll explain a high level idea that will likely solve the problems.
>
> Currently the plugins are authored by having a set of arbitrary source
> files as defined by the  /  directives,
> which also declares where these files should be copied to into the cordova
> native app project. Additionally, if the plugin requires
> changing resource files or adding additional configurations, they must
> make use of several directives which may include:
>
> - config-file
> - edit-config
> - resource-file
> - lib-file
> - framework
> - source-file / header-file
> - asset
>
>
> Most of these works well enough, but shouldn't be necessary to begin with.
> Others, are very finicky or are barely usable due to bugs or other caveats
> (e.g. config-file and edit-config)
>
> The second issue with the way that Cordova plugins are traditionally
> authored (based on the Official Apache plugins) is that they
> aren't unit testable. They can only really be tested as part of a real
> cordova project, which we currently do via cordova-paramedic.
> This is because there is a disconnect between the plugin sources and an
> actual native project.
>
> So I've been experimenting with authoring cordova plugins using a native
> project that gets imported a cordova project. Right now
> my experimentation has been exclusively with the Android platform, so I'll
> be using more Android-specific examples.
>
> But my experimentation has me building a cordova plugin that instead of
> containing loose java source files, they contain an actual
> Gradle project that builds an Android Library. This means that the Cordova
> Plugin has it's own:
>
> - Source files
> - AndroidManifest
> - resources
> - Gradle configs & dependency management
>
> With these tools at the plugin's author disposal... it should eliminate,
> or mostly eliminate the need of the aforementioned directives:
>
> - edit-config
>
> Is no longer required to edit AndroidManifest.xml, but may still be
> required to edit config.xml (but is there really a need to?). Instead
> native libraries have their own AndroidManifest.xml which will get merged
> with the App's manifest.
>
> - lib-file
>
> A native library can bundle their own lib-files.
>
> - resource-file
>
> A native library can bundle their own resource files.
>
> - framework
>
> A native library has it's own gradle file to manage frameworks/dependencies
>
> - source-file / header-file
>
> A native library has it's own file structure for their source files,
> whether java or native C++ modules.
>
> - config-file*
>
> While won't be needed to edit AndroidManifest.xml for the same reason as
> edit-config, which was a common use case...
> It will still be required for setting up cordova Feature tags/declarations
> which gets placed into `config.xml`.
>
> - asset*
>
> Untested, I'm not sure if assets will get merged in a way that is usable
> by the app. So this directive may still be relevant.
>
> Additionally, the js-module directive will still be relevant as the native
> project has no concept of setting up the webview JS modules.
>
> *To be clear*, I'm not suggesting that the current plugin.xml directives
> to be deprecated or removed. They are still going
> to be required to support any cordova plugin authored in a traditional
> method. However, with the module method, most of these directives won't be
> necessary to use.
> In fact, I think the module method could continue to use any one of the
> existing directives if they choose to, but in all likeliness, there won't
> be a need to. In
> practice we may want to discourage people to use the "legacy" directives
> so that support could be considered to be dropped in the future.
>
> I foresee a new directive being created to declare the "module" directory,
> which is the root folder of a native project, which 

Re: [DISCUSS] Android - New Minimum SDK?

[julio cesar sanchez]

As far as I know the problems with upgradeable webviews on some device
manufacturers affect all versions, not only 5.0. Some vendors decide to not
make it updatable, and others use their own implementation instead of the
system one.

Anyway, I’m ok with 24

El El mié, 8 mar 2023 a las 1:49, Norman Breau 
escribió:

> I'm fine with min SDK 24. I do think however we should support
> the factory webview version (based on AOSP) instead of picking a chrome
> version number, purely because that isn't very enforceable (Could lead
> to poor app user experience).
> But if required we can discuss that further in another thread since it's
> kind of off-topic to Min SDK.
>
> I also agree that if we are picking Min SDK numbers, we should pick the
> base (e.g. Support Android 7.0+ instead of 7.1+).
> If I recall correctly, it was chosen for Android 5.1 purely because
> there was known issues regarding upgradeable webviews on some device
> manufacturers with Android 5.0.
>
> FYI I skipped API 25 because there was a lack of data points.
>
> On 2023-03-07 7:55 p.m., julio cesar sanchez wrote:
> > Any other opinions about it?
> >
> >
> >
> > El jueves, 8 de diciembre de 2022, julio cesar sanchez <
> > jcesarmob...@gmail.com> escribió:
> >
> >> I was going to propose to bump the minSDK to 23 since we have been in 22
> >> for a few versions, but I think going to 27 is too much and would make
> >> users to not update or to move to something else.
> >>
> >> The truth is, with google support libraries we won't really be cleaning
> up
> >> that much code since the support libraries (android x core and such)
> take
> >> care of that.
> >> cordova-android has 2 SDK_INT version checks, one for N and another for
> M,
> >> statusbar plugin has one for M, camera plugin has one for 28,
> inappbrowser
> >> has one for O.
> >> We probably have more code for supporting old cordova versions (in the
> >> plugins) that probably nobody uses than for supporting old android
> versions.
> >> BTW, you missed Android 7.1 (SDK 25).
> >>
> >> Also, I wouldn't go with Android 8.1, in any case I would choose 8.0, it
> >> was weird when we went with Android 5.1 instead of 5.0 or 6.0 as the
> code
> >> to support it was basically the same as for supporting 5.0.
> >> And related to that, I would count minor versions as one major, so
> Android
> >> 8 should be 8.0 and 8.1, so the usage would be 8.5%, and Android 7 (7.0
> and
> >> 7.1) would be close to the 5% threshold. So we should go to minSDK 24
> tops.
> >>
> >> We can also do as Capacitor does and say that we support Chrome 60+ (or
> >> the version we decide), so if people use an emulator where the default
> >> version is older, it's not supported despite the Android version is. But
> >> for real devices, the % of out of date WebViews is much much smaller.
> >>
> >>
> >>
> >> El jue, 8 dic 2022 a las 16:59, Norman Breau ()
> >> escribió:
> >>
> >>> Hi Apache Cordova community,
> >>>
> >>> I'm writing to propose that we increase our Minimum SDK on our next
> >>> major release of cordova-android
> >>> and I wanted to get a feel of the Cordova community of what a new good
> >>> target to be, should we increase
> >>> the minimum SDK.
> >>>
> >>> First I wanted to link a resource for the Android OS market share by
> >>> Android Version[1].
> >>>
> >>> Based on November 2021-2022 the data summarized as follows:
> >>>
> >>> Android 5.1 (API 22) - 1.32%
> >>> Android 6.0 (API 23) - 2.45%
> >>> Android 7.0 (API 24) - 2.64%
> >>> Android 8.0 (API 26) - 2.61%
> >>> Android 8.1 (API 27) - 5.89%
> >>> Android >= 9.0 (API 28+) - 9% or greater
> >>>
> >>> It's desirable to drop old versions eventually because maintaining
> >>> backwards support can be difficult, particularly when Android
> introduces
> >>> new systems where it may only be available on newer API devices.
> >>> Additionally, every Android OS version could potentially be running
> >>> a really old system webview assuming the device has never been updated
> >>> from factory settings. Which based on the Android AOSP emulators, are
> as
> >>> follows:
> >>>
> >>> Android 5.1 - Chrome 39
> >>> Android 6.0 - Chrome 44
> >>> Android 7.0 - Chrome 52
> >>> Android 8.0 - Chrom

Re: [DISCUSS] Android - New Minimum SDK?

[julio cesar sanchez]

Any other opinions about it?



El jueves, 8 de diciembre de 2022, julio cesar sanchez <
jcesarmob...@gmail.com> escribió:

> I was going to propose to bump the minSDK to 23 since we have been in 22
> for a few versions, but I think going to 27 is too much and would make
> users to not update or to move to something else.
>
> The truth is, with google support libraries we won't really be cleaning up
> that much code since the support libraries (android x core and such) take
> care of that.
> cordova-android has 2 SDK_INT version checks, one for N and another for M,
> statusbar plugin has one for M, camera plugin has one for 28, inappbrowser
> has one for O.
> We probably have more code for supporting old cordova versions (in the
> plugins) that probably nobody uses than for supporting old android versions.
> BTW, you missed Android 7.1 (SDK 25).
>
> Also, I wouldn't go with Android 8.1, in any case I would choose 8.0, it
> was weird when we went with Android 5.1 instead of 5.0 or 6.0 as the code
> to support it was basically the same as for supporting 5.0.
> And related to that, I would count minor versions as one major, so Android
> 8 should be 8.0 and 8.1, so the usage would be 8.5%, and Android 7 (7.0 and
> 7.1) would be close to the 5% threshold. So we should go to minSDK 24 tops.
>
> We can also do as Capacitor does and say that we support Chrome 60+ (or
> the version we decide), so if people use an emulator where the default
> version is older, it's not supported despite the Android version is. But
> for real devices, the % of out of date WebViews is much much smaller.
>
>
>
> El jue, 8 dic 2022 a las 16:59, Norman Breau ()
> escribió:
>
>>
>> Hi Apache Cordova community,
>>
>> I'm writing to propose that we increase our Minimum SDK on our next
>> major release of cordova-android
>> and I wanted to get a feel of the Cordova community of what a new good
>> target to be, should we increase
>> the minimum SDK.
>>
>> First I wanted to link a resource for the Android OS market share by
>> Android Version[1].
>>
>> Based on November 2021-2022 the data summarized as follows:
>>
>> Android 5.1 (API 22) - 1.32%
>> Android 6.0 (API 23) - 2.45%
>> Android 7.0 (API 24) - 2.64%
>> Android 8.0 (API 26) - 2.61%
>> Android 8.1 (API 27) - 5.89%
>> Android >= 9.0 (API 28+) - 9% or greater
>>
>> It's desirable to drop old versions eventually because maintaining
>> backwards support can be difficult, particularly when Android introduces
>> new systems where it may only be available on newer API devices.
>> Additionally, every Android OS version could potentially be running
>> a really old system webview assuming the device has never been updated
>> from factory settings. Which based on the Android AOSP emulators, are as
>> follows:
>>
>> Android 5.1 - Chrome 39
>> Android 6.0 - Chrome 44
>> Android 7.0 - Chrome 52
>> Android 8.0 - Chrome 58
>> Android 8.1 - Chrome 61
>> Android 9.0+ - Chrome 66+
>>
>> I think traditionally, Cordova uses a 5% threshold to determine
>> supported devices, so I propose that for cordova-android@12, we increase
>> the Minimum SDK to API 27 or Android 8.1,
>> which contains 2 main benefits: 1) Allowing us to start cleaning up the
>> codebase significantly and 2) Cordova apps can start assuming a much
>> better JS feature support in their webviews as
>> can start assuming that the webview will be at least version 61 for most
>> devices.
>>
>> [1] https://gs.statcounter.com/android-version-market-share
>>
>> Cheers,
>> Norman
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>

Re: statusbar styles decision

[julio cesar sanchez]

Since there is no consensus, I've created a poll on the new GitHub
discussions, hopefully we would get some user opinions/votes

https://github.com/apache/cordova/discussions/372

El mar, 25 oct 2022 a las 17:19, Jesse () escribió:

> #1
> The intent of default was always to do the platform / system default
> thing.
>
> Default on Android need not look like default on iOS
>
> > On Oct 25, 2022, at 8:01 AM, julio cesar sanchez 
> wrote:
> >
> > The funny thing is default is not the default value, the default value
> is
> > lightContent. It’s called default just to match the iOS name. So another
> > reason to deprecate it.
> >
> >> El El mar, 25 oct 2022 a las 16:37, Norman Breau <
> nor...@normanbreau.com>
> >> escribió:
> >>
> >> I think if we (Apache) used the term "default", it should be referencing
> >> our default, and not necessarily the underlying platform's default.
> >>
> >> Therefore, I think #2 might be the best path moving forward. Adding
> >> a styleDarkContent will be symmetrical to the styleLightContent
> counterpart
> >> (we have light & dark opposites). And if the user wants to match the
> system
> >> theme, having styleSystem is think is a clear indication of that
> >> behaviour, more
> >> so than a styleDefault.
> >>
> >> So +1 for Option #2.
> >>
> >>> On 2022-10-25 6:08 a.m., julio cesar sanchez wrote:
> >>> The statusbar plugin has this styles:
> >>>
> >>>- *StatusBar.styleDefault*: Use the default statusbar (dark text,
> for
> >>>light backgrounds)
> >>>- *StatusBar.styleLightContent:* Use the lightContent statusbar
> >> (light
> >>>text, for dark backgrounds).
> >>>
> >>> This was enough until iOS 13 came out, then Apple added DarkContent to
> be
> >>> the dark text and changed default to change according to the user
> theme.
> >>>
> >>> Since *StatusBar.**styleDefault* was setting the text to whie in some
> >> cases
> >>> now, I changed it to work as the docs say, always use dark text (asked
> on
> >>> the issue and users wanted it like that). But after it was merged, some
> >>> users started to say that we should provide a new
> >>> *StatusBar.styleDarkContent* and make *StatusBar.**styleDefault *work
> as
> >>> the native default value (change according to the configured user
> theme).
> >>>
> >>> So, what should we do?
> >>>
> >>> 1) Add a new *StatusBar.styleDarkContent *method that would work as the
> >>> *StatusBar.**styleDefault* works now, dark text, and change
> *StatusBar.*
> >>> *styleDefault* to use the native default value so it changes according
> to
> >>> the user theme.
> >>>
> >>> 2) Add a new *StatusBar.styleDarkContent *method that would work as the
> >>> styleDefault works now, dark text, add another new
> >> *StatusBar.styleSystem*
> >>> (or similar name)  to use the native default value so it changes
> >> according
> >>> to the user theme, and deprecate *StatusBar.**styleDefault*.
> >>>
> >>> 3) Keep the *StatusBar.**styleDefault* for dark text and add a new
> >>> *StatusBar.styleSystem* (or similar name) to make the status bar change
> >>> according to the user theme.
> >>>
> >>> Next release is going to be a major release, so we shouldn't worry
> about
> >>> breaking changes. But not sure which change would be the least
> confusing
> >>> for users, matching the style names to the native iOS names and their
> >>> bebavior, keep default as dark text as that's what is documented or
> use a
> >>> more neutral name for style changing according to the theme.
> >>>
> >>> Note, it's not clear if we can accomplish the status bar style change
> >>> according to the user/phone theme on Android.
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >> For additional commands, e-mail: dev-h...@cordova.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Error while running cordova

[julio cesar sanchez]

As Norman told you in your previous mail, this mailing is for discussions
regarding the development of Cordova
(CLI, platforms, plugins, etc.) only.

For questions or support, please start a discussion inside GitHub at
https://github.com/apache/cordova/discussions

El El jue, 5 ene 2023 a las 16:11, Deepak Goel  escribió:

> Hello
>
> I am a newbie.
>
> I installed cordova for windows. I was playing around a bit with the
> startup (https://cordova.apache.org/).
>
> When I try to run cordova for android, i get the following error:
>
> Built the following apk(s):
>
>
> -
>
>  
> D:\Saksham\cordova\DaTaraMandal\platforms\android\app\build\outputs\apk\debug\app-debug.apk
> Checking Java JDK and Android SDK versions
> ANDROID_SDK_ROOT=C:\Users\Admin\AppData\Local\Android\sdk (recommended
> setting)
> ANDROID_HOME=undefined (DEPRECATED)
> Using Android SDK: C:\Users\Admin\AppData\Local\Android\sdk
> Command failed with exit code 1: apkanalyzer manifest target-sdk
>
> D:\Saksham\cordova\DaTaraMandal\platforms\android\app\build\outputs\apk\debug\app-debug.apk
>
> *'sh' is not recognized as an internal or external command,operable program
> or batch file.*
>
> -
>
> Any idea what to do?
>
>
> Deepak
> "The greatness of a nation can be judged by the way its animals are treated
> - Mahatma Gandhi"
>
> +91 73500 12833
> deic...@gmail.com
>
> Facebook: https://www.facebook.com/deicool
> LinkedIn: www.linkedin.com/in/deicool
>
> "Plant a Tree, Go Green"
>
> Make In India : http://www.makeinindia.com/home
>

Re: [DISCUSS] cordova-lib 11.1.0 Release

[julio cesar sanchez]

Ok, I think we should do a minor since we include the deprecation of some
platforms and then we can do a major soon removing those deprecated
platforms and the pinning for the remaining.


El El mar, 13 dic 2022 a las 18:22, Norman Breau 
escribió:

> Bumping a pin from android v10 to v11 should be considered a breaking
> change.
> If users are relying on this behavior in scripts or builds, it may
> unexpectedly break.
>
> Removing the pin logic while I think I agree with, it's still changing
> the behavior so would
> also be considered a breaking change. But if we proceed with that we can
> explain in the
> release blog that they can specify a version if they want to assert a
> specific version, e.g:
>
> cordova platform add android@11
>
> So we should probably wait before we change the pin logic until we build
> a cordova-lib@12
> regardless if we decide to remove the pinning logic altogether, or
> simply bump the android pin.
>
> On 2022-12-13 1:13 p.m., Bryan Ellis wrote:
> > I am not entirely sure. I believe we had only pinned the platform major
> > with a major release.
> >
> >
> > I think the pinning logic should be removed. That is why I created this
> PR
> > for the next major: https://github.com/apache/cordova-lib/pull/894
> >
> >
> > I feel that "cordova platform add " should always install the
> > latest, and if any user wants a specific version, they should supply it.
> > "@". Similar to how npm works when adding a package
> for
> > the first time, fetching the latest.
> >
> >
> > I am not sure if there is any reason we should not bump the pinning.
> Since
> > it is a minor version, I am open to the idea of bumping the pinning.
> >
> >
> > Any objections?
> >
> >
> >
> > On Tue, Dec 13, 2022 at 6:04 PM julio cesar sanchez <
> jcesarmob...@gmail.com>
> > wrote:
> >
> >> Shouldn’t we pin cordova-android 11?
> >> Or that requires a major bump that we don’t want to do at the moment?
> >>
> >> But cordova-android 11 is a requirement to publish apps on google play
> >> since November for existing apps and August for new apps.
> >>
> >> El El mar, 13 dic 2022 a las 5:05, Bryan Ellis 
> >> escribió:
> >>
> >>> Does anyone have any reason to delay a release for cordova-lib?
> >>>
> >>> * cordova-lib (11.1.0)
> >>>
> >>> https://github.com/apache/cordova-lib/compare/rel/11.0.0..master <
> >>> https://github.com/apache/cordova-lib/compare/rel/11.0.0..master>
> >>>
> >>> Any additional outstanding changes to land?
> >>>
> >>> If not, I will start the release process shortly.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [DISCUSS] cordova-lib 11.1.0 Release

[julio cesar sanchez]

Shouldn’t we pin cordova-android 11?
Or that requires a major bump that we don’t want to do at the moment?

But cordova-android 11 is a requirement to publish apps on google play
since November for existing apps and August for new apps.

El El mar, 13 dic 2022 a las 5:05, Bryan Ellis  escribió:

> Does anyone have any reason to delay a release for cordova-lib?
>
> * cordova-lib (11.1.0)
>
> https://github.com/apache/cordova-lib/compare/rel/11.0.0..master <
> https://github.com/apache/cordova-lib/compare/rel/11.0.0..master>
>
> Any additional outstanding changes to land?
>
> If not, I will start the release process shortly.

Re: [DISCUSS] Android - New Minimum SDK?

[julio cesar sanchez]

I was going to propose to bump the minSDK to 23 since we have been in 22
for a few versions, but I think going to 27 is too much and would make
users to not update or to move to something else.

The truth is, with google support libraries we won't really be cleaning up
that much code since the support libraries (android x core and such) take
care of that.
cordova-android has 2 SDK_INT version checks, one for N and another for M,
statusbar plugin has one for M, camera plugin has one for 28, inappbrowser
has one for O.
We probably have more code for supporting old cordova versions (in the
plugins) that probably nobody uses than for supporting old android versions.
BTW, you missed Android 7.1 (SDK 25).

Also, I wouldn't go with Android 8.1, in any case I would choose 8.0, it
was weird when we went with Android 5.1 instead of 5.0 or 6.0 as the code
to support it was basically the same as for supporting 5.0.
And related to that, I would count minor versions as one major, so Android
8 should be 8.0 and 8.1, so the usage would be 8.5%, and Android 7 (7.0 and
7.1) would be close to the 5% threshold. So we should go to minSDK 24 tops.

We can also do as Capacitor does and say that we support Chrome 60+ (or the
version we decide), so if people use an emulator where the default version
is older, it's not supported despite the Android version is. But for real
devices, the % of out of date WebViews is much much smaller.



El jue, 8 dic 2022 a las 16:59, Norman Breau ()
escribió:

>
> Hi Apache Cordova community,
>
> I'm writing to propose that we increase our Minimum SDK on our next
> major release of cordova-android
> and I wanted to get a feel of the Cordova community of what a new good
> target to be, should we increase
> the minimum SDK.
>
> First I wanted to link a resource for the Android OS market share by
> Android Version[1].
>
> Based on November 2021-2022 the data summarized as follows:
>
> Android 5.1 (API 22) - 1.32%
> Android 6.0 (API 23) - 2.45%
> Android 7.0 (API 24) - 2.64%
> Android 8.0 (API 26) - 2.61%
> Android 8.1 (API 27) - 5.89%
> Android >= 9.0 (API 28+) - 9% or greater
>
> It's desirable to drop old versions eventually because maintaining
> backwards support can be difficult, particularly when Android introduces
> new systems where it may only be available on newer API devices.
> Additionally, every Android OS version could potentially be running
> a really old system webview assuming the device has never been updated
> from factory settings. Which based on the Android AOSP emulators, are as
> follows:
>
> Android 5.1 - Chrome 39
> Android 6.0 - Chrome 44
> Android 7.0 - Chrome 52
> Android 8.0 - Chrome 58
> Android 8.1 - Chrome 61
> Android 9.0+ - Chrome 66+
>
> I think traditionally, Cordova uses a 5% threshold to determine
> supported devices, so I propose that for cordova-android@12, we increase
> the Minimum SDK to API 27 or Android 8.1,
> which contains 2 main benefits: 1) Allowing us to start cleaning up the
> codebase significantly and 2) Cordova apps can start assuming a much
> better JS feature support in their webviews as
> can start assuming that the webview will be at least version 61 for most
> devices.
>
> [1] https://gs.statcounter.com/android-version-market-share
>
> Cheers,
> Norman
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: statusbar styles decision

[julio cesar sanchez]

The funny thing is default is not the default value, the default value is
lightContent. It’s called default just to match the iOS name. So another
reason to deprecate it.

El El mar, 25 oct 2022 a las 16:37, Norman Breau 
escribió:

> I think if we (Apache) used the term "default", it should be referencing
> our default, and not necessarily the underlying platform's default.
>
> Therefore, I think #2 might be the best path moving forward. Adding
> a styleDarkContent will be symmetrical to the styleLightContent counterpart
> (we have light & dark opposites). And if the user wants to match the system
> theme, having styleSystem is think is a clear indication of that
> behaviour, more
> so than a styleDefault.
>
> So +1 for Option #2.
>
> On 2022-10-25 6:08 a.m., julio cesar sanchez wrote:
> > The statusbar plugin has this styles:
> >
> > - *StatusBar.styleDefault*: Use the default statusbar (dark text, for
> > light backgrounds)
> > - *StatusBar.styleLightContent:* Use the lightContent statusbar
> (light
> > text, for dark backgrounds).
> >
> > This was enough until iOS 13 came out, then Apple added DarkContent to be
> > the dark text and changed default to change according to the user theme.
> >
> > Since *StatusBar.**styleDefault* was setting the text to whie in some
> cases
> > now, I changed it to work as the docs say, always use dark text (asked on
> > the issue and users wanted it like that). But after it was merged, some
> > users started to say that we should provide a new
> > *StatusBar.styleDarkContent* and make *StatusBar.**styleDefault *work as
> > the native default value (change according to the configured user theme).
> >
> > So, what should we do?
> >
> > 1) Add a new *StatusBar.styleDarkContent *method that would work as the
> > *StatusBar.**styleDefault* works now, dark text, and change *StatusBar.*
> > *styleDefault* to use the native default value so it changes according to
> > the user theme.
> >
> > 2) Add a new *StatusBar.styleDarkContent *method that would work as the
> > styleDefault works now, dark text, add another new
> *StatusBar.styleSystem*
> > (or similar name)  to use the native default value so it changes
> according
> > to the user theme, and deprecate *StatusBar.**styleDefault*.
> >
> > 3) Keep the *StatusBar.**styleDefault* for dark text and add a new
> > *StatusBar.styleSystem* (or similar name) to make the status bar change
> > according to the user theme.
> >
> > Next release is going to be a major release, so we shouldn't worry about
> > breaking changes. But not sure which change would be the least confusing
> > for users, matching the style names to the native iOS names and their
> > bebavior, keep default as dark text as that's what is documented or use a
> > more neutral name for style changing according to the theme.
> >
> > Note, it's not clear if we can accomplish the status bar style change
> > according to the user/phone theme on Android.
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

statusbar styles decision

[julio cesar sanchez]

The statusbar plugin has this styles:

   - *StatusBar.styleDefault*: Use the default statusbar (dark text, for
   light backgrounds)
   - *StatusBar.styleLightContent:* Use the lightContent statusbar (light
   text, for dark backgrounds).

This was enough until iOS 13 came out, then Apple added DarkContent to be
the dark text and changed default to change according to the user theme.

Since *StatusBar.**styleDefault* was setting the text to whie in some cases
now, I changed it to work as the docs say, always use dark text (asked on
the issue and users wanted it like that). But after it was merged, some
users started to say that we should provide a new
*StatusBar.styleDarkContent* and make *StatusBar.**styleDefault *work as
the native default value (change according to the configured user theme).

So, what should we do?

1) Add a new *StatusBar.styleDarkContent *method that would work as the
*StatusBar.**styleDefault* works now, dark text, and change *StatusBar.*
*styleDefault* to use the native default value so it changes according to
the user theme.

2) Add a new *StatusBar.styleDarkContent *method that would work as the
styleDefault works now, dark text, add another new *StatusBar.styleSystem*
(or similar name)  to use the native default value so it changes according
to the user theme, and deprecate *StatusBar.**styleDefault*.

3) Keep the *StatusBar.**styleDefault* for dark text and add a new
*StatusBar.styleSystem* (or similar name) to make the status bar change
according to the user theme.

Next release is going to be a major release, so we shouldn't worry about
breaking changes. But not sure which change would be the least confusing
for users, matching the style names to the native iOS names and their
bebavior, keep default as dark text as that's what is documented or use a
more neutral name for style changing according to the theme.

Note, it's not clear if we can accomplish the status bar style change
according to the user/phone theme on Android.

Re: Plugin Search

[julio cesar sanchez]

+1 to option #2

Niklas, option 2 already mentions having a link to the npm search with
cordova ecosystem prefilled for easier searching of other 3rd party plugins

El El vie, 21 oct 2022 a las 16:39, Niklas Merz 
escribió:

> I'm +1 on #2, too. Making clear which plugins are Official and supported
> actively is a good idea. And just a simple note on how to find more on
> npm is enough IMHO.
>
> On October 21, 2022, Norman Breau  wrote:
> > Hi Team,
> >
> > I want to reach a final verdict on how deal with the broken search
> > page
> > at https://cordova.apache.org/plugins/
> >
> > We have an active issue being tracked at
> > https://github.com/apache/cordova-docs/issues/1128 but in summary,
> > the rest service used to power the search has gone offline and
> > doesn't
> > appear to be coming back.
> >
> > Throughout the thread there has been several ideals about how to move
> > forward including:
> >
> > 1. Using another third-party API service: https://api-docs.npms.io/
> > 2. Having a static page listing the officially supported Apache
> > plugins,
> > with a link to https://www.npmjs.com/search?q=ecosystem%3Acordova
> > 3. Removing the page entirely, maybe with a blog post explaining how
> > to
> > find third-party plugins.
> >
> > Additionally there are few ideas floated around with using the NPM
> > Couch
> > API directly, but there may be terms of use issues involved without
> > having self-managed server hosting a mirror.
> >
> > Personally, I vote -1 for #1 and #3. npms.io doesn't have a clear
> > terms
> > of use, as far as I can find. I'm not sure if the API matches the old
> > npmsearch that we did use, and we may just run into the same issue
> > down the road. For #3, community members have already explicitly
> > expressed dissent with removing the page entirely.
> >
> > I vote +1 for #2, having the static page with a mention + link to NPM
> > for third-party plugins. I think this is most likely the best path
> > forward.
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
>

Re: Interest in contributing to cordova-paramedic project

[julio cesar sanchez]

Hi,

The Apache projects are public and require no permissions to contribute,
you fork the project and send a pull request fixing the issue and the team
will evaluate and merge if they consider it a good contribution.

Then , if you keep contributing over time and your contributions are
considered valuable a member can propose you to be a maintainer with write
permissions so you don’t need to wait for reviews to merge (but still a
good practice to wait for input/approval despite you don’t need to)

El El sáb, 30 jul 2022 a las 10:32,  escribió:

> Hi there,
>
> My name is Hudson and I am a QA Automation Engineer. I am working
> especially with mobile frameworks, including Cordova. I am currently using
> cordova-paramedic for a set of Cordova plugin tests. I have run into a
> couple of issues with cordova-paramedic along the way and I would be
> willing to help contribute to this project if possible to help resolve
> these and other issues. How does the process work for being added as a
> contributor and gaining access to create PRs for open issues?
>
> Thanks,
> Hudson
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [DISCUSS] cordova-android 11.0.0 Release

[julio cesar sanchez]

The 11.0.0 planning board
 has two pending "To
Do" .

Also, I've sent two small PRs that could be included.

El mar, 28 jun 2022 a las 14:19, Bryan Ellis () escribió:

> Does anyone have any reason to delay a release for the following platform?
>
> * cordova-android (11.0.0)
>   * https://github.com/apache/cordova-android/compare/rel/10.1.2...master
> 
>
> Any additional outstanding changes to land?
>
> If not, I will start the release process shortly.

Re: Dependabot

[julio cesar sanchez]

In this case the package-lock was out of sync with the package.json (it had
v6.x.x while package.json had 7.x.x), so if we have more packages with the
same problem we should fix them.

But if the package-lock is ok, then I think we can just merge the
dependabot PRs, what’s the advantage of having it if we still send PRs
manually to do the same?


El martes, 7 de junio de 2022, Norman Breau 
escribió:

>
> Hi Team,
>
> Just curious on other thoughts on Dependabot now that Apache enabled them
> across the repos. Do we review and merge them as is? Should we build PRs
> like https://github.com/apache/cordova-js/pull/255 to regenerate
> package-lock which will result in dependent bot to close their PRs.
> Case-by-case basis?
>
> Personally I think I favour the manual PR approach as it will squash
> several dependent PRs into one, and dependabot is smart enough to notice
> when their PR is out-dated.
>
> Cheers,
> Norman
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Good and less good ways to handle grumpy GitHub comments

[julio cesar sanchez]

Being grumpy causes more grumpiness. You can start by not being grumpy to
unpaid volunteers that are dedicating a considerable  amount of their spare
time to maintain the tools you use for free.
I see Norman’s comment totally correct, we make breaking changes every year
on every major version. If your problem is related to the whitelist name
change, the fix should be as easy as uninstalling the plugin. That would
have happened even if the name didn’t change because the plugin was
integrated into the platform, so you would have to uninstall the plugin
anyway.

He invites you to the mail list to discuss how we can improve the release
process to make breaking changes easier to manage and instead of proposing
constructive things like creating an upgrade guide, you bring more
grumpiness by commenting how we should answer to grumpy users and try to
embarrass him in front of the list.



El El sáb, 14 may 2022 a las 11:46, Richard Möhn 
escribió:

> Hi folks,
>
> a drive-by note – this is a great way to handle a grumpy comment on GitHub:
>
> https://github.com/apokalipto/devise_saml_authenticatable/pull/213#issuecomment-1126197865
>
> This way of handling a grumpy comment causes more grumpiness:
> https://github.com/apache/cordova-android/pull/1138#issuecomment-1104923029
>
> Best,
>
> Richard
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [VOTE] Deprecate cordova-osx platform

[julio cesar sanchez]

I vote +1

El El sáb, 12 mar 2022 a las 10:24, Niklas Merz 
escribió:

> As discussed for the latest release of osx and a few times before [1],
> we could officially deprecate the osx platform. It seems it does not
> have many users anymore and we can offer good alternatives with Catalyst
> in cordova-ios and cordova-electron. Version 7.0.0 of osx already has a
> deprecation notice in the announcement blog post [2].
>
> I will follow this process: https://github.com/apache/cordova-
> contribute/blob/master/deprecation.md
>
> I vote +1
>
> [1] https://lists.apache.org/thread/lqq2xoy3pjqcyl052gv0qom2f31zgg8k
> [2] https://cordova.apache.org/announcements/2022/03/09/osx-release-
> 7.0.0.html
>

Re: [VOTE] Statusbar Plugin 3.0.0 Release

[julio cesar sanchez]

I vote -1

Just noticed the engines are not correctly set in the package.json and that
will prevent people from installing the plugin:

"3.0.0": {
"cordova": ">100"
}

Will send a pull request fixing it as soon as github is back online.


El vie, 19 nov 2021 a las 17:09, Niklas Merz ()
escribió:

> I vote +1
>
> I did:
> * hash & signature check
> * checked tag
> * quick test on ios
> * checked licenses and headers
> * npm audit
>
> On November 19, 2021, Erisu  wrote:
> > Please review and vote on this Cordova Plugin Statusbar Release v3.0.0
> > by replying to this email (and keep discussion on the DISCUSS thread)
> >
> > The archive has been published to dist/dev:
> >
> >  https://dist.apache.org/repos/dist/dev/cordova/statusbar-v3.0.0
> >
> > The package was published from its corresponding git tag:
> >
> >  cordova-plugin-statusbar: 3.0.0 (d95cc821fc)
> >
> > Upon a successful vote I will upload the archive to dist/, publish it
> > to npm, and post the blog post.
> >
> > 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 sub-
> > dependencies have Apache-compatible licenses
> > * Ensured the npm audit report was sufficient for release
> >
> > * AS there are issues within the CI testing service accross ALL
> > plugins, for this release I have manually tested:
> >  * Build Mobile Spec project for iOS & Android w/ CLI
> >  * Run Mobile Spec project on iOS & Android simulator w/ CLI
> >  * Executed the Mobile Spec Jasmine tests on iOS & Android
> >
> > Audit Report:
> >
> >  0 vulnerabilities found
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
>

Re: [DISCUSS] cordova-plugin-statusbar 3.0.0 Major Release

[julio cesar sanchez]

No objections, you can release it.

El martes, 12 de octubre de 2021, Bryan Ellis  escribió:

> Does anyone have any reason to delay a cordova-plugin-statusbar major
> release (3.0.0)?
>
> Any additional outstanding changes to land?
>
> == Changes ==
>
> https://github.com/apache/cordova-plugin-statusbar/
> compare/rel/2.4.3...master  cordova-plugin-statusbar/compare/rel/2.4.3...master>
>
>

Re: [DISCUSS] cordova-plugin-camera 5.0.3 Patch Release

[julio cesar sanchez]

Ship it!

I mean, you can start the release process.

El mié, 28 jul 2021 a las 7:40, Bryan Ellis () escribió:

> Does anyone have any reason to delay a cordova-plugin-camera patch release
> (5.0.3)?
>
> Any additional outstanding changes to land?
>
> If not, I will start the release process shortly.
>
>
> == Note ==
>
> The primary purpose of this patch release is to update the pinning of the
> Cordova-Android platform. Starting from this patch release and the
> remaining of the 5.x releases, the cordova-android pinning should be
> “<10.0.0”.
>
> == Changes ==
>
> https://github.com/apache/cordova-plugin-camera/compare/rel/5.0.2...master
> 

Re: [DISCUSS] cordova-android 10.0.1 Patch Release

[julio cesar sanchez]

There are some changes that say that it requires

Java Development Kit (JDK) 11

But my changes allowed any JDK, didn’t require 11

Unless we did more changes later that require JDK 11 and I missed them.

El El lun, 26 jul 2021 a las 15:39, Norman Breau 
escribió:

> I'd like to see https://github.com/apache/cordova-android/issues/1290
> included in 10.0.1 release
>
> I'll try to prepare a fix right now.
>
> On 2021-07-26 10:10 a.m., Bryan Ellis wrote:
> > Does anyone have any reason to delay a cordova-android patch release
> (10.0.1)?
> >
> > Any additional outstanding changes to land?
> >
> > If not, I will start the release process shortly.
> >
> >
> > == Changes ==
> >
> > https://github.com/apache/cordova-android/compare/rel/10.0.0...master <
> https://github.com/apache/cordova-android/compare/rel/9.1.0...master>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [Cordova dev] Task :app:stripDebugDebugSymbols / No version of NDK matched [...]

[julio cesar sanchez]

Also, I think the android.ndkVersion can be in the build.gradle of the
plugin too, not needed to be on Cordova's gradle files (at least docs say
it can be in a module build.gradle, but I could be wrong)
If we put it in cordova's gradle and people don't have the ndk, would it
error?

But having it in the plugins gradle could lead to version mismatch with
other plugins, so might make sense to make cordova create the variable if
the config.xml has some preference related to it.

El vie, 16 jul 2021 a las 18:39, Norman Breau ()
escribió:

> My point is, how can Cordova fulfill the document requirements for
> something it doesn't require?
> The requirements will depend on the plugin that does uses NDK, and what
> NDK version it depends on.
>
> If a plugin requires NDK to be installed for it to work, then it should
> be up to the plugin to document
> that as it is their requirement.
>
> On 2021-07-16 12:03 a.m., @brodybits - Chris Brody wrote:
> > Thanks for the response. Yes I think none of the Apache Cordova
> maintained
> > plugins would use C or C++ code with Android NDK, but there are some
> > third-party plugins which do use at least C code with NDK and
> > cordova-sqlite-storage from myself would be a major example.
> >
> > Setting ANDROID_NDK_HOME directly in my profile did resolve this issue,
> as
> > recommended in one of the solutions in Stack Overflow, but it does lead
> to
> > this warning:
> >
> > *> Task :app:stripDebugDebugSymbols* UP-TO-DATE
> >
> > WARNING: Support for ANDROID_NDK_HOME is deprecated and will be removed
> in
> > the future. Use android.ndkVersion in build.gradle instead.
> >
> > Support for ANDROID_NDK_HOME is deprecated and will be removed in the
> > future. Use android.ndkVersion in build.gradle instead.
> >
> > I think this comes from simply installing the most recent version of the
> > NDK from Android Studio. I *think* this will not be an issue for someone
> > who does not install NDK but cannot say for sure right now. And I do not
> > see much compelling reason to install an older version of the NDK either
> > from Android Studio or from a download link
> >
> > As I said before, React Native does seem to handle this a little more
> > gracefully.
> >
> > While I would agree that this would not be really *caused* by Cordova,
> and
> > not necessarily *needed* to be fixed for Cordova to function properly, I
> > would certainly not consider this to be a good form of app developer
> > experience for someone between NDK, Cordova, and a plugin such as
> > cordova-sqlite-storage.
> >
> > Should we consider simply fixing this in the documentation for now?
> >
> >
> > On Tue, Jul 13, 2021 at 11:38 AM Jesse  wrote:
> >
> >> Got it. Thanks.
> >>
> >>> On Jul 13, 2021, at 7:11 AM, julio cesar sanchez <
> jcesarmob...@gmail.com>
> >> wrote:
> >>> Jesse, Norman means NDK code, which is considered native (stands for
> >> Native
> >>> Development Kit).
> >>> We don't have any of those.
> >>> We have plenty of java code, but that's not affected by the NDK.
> >>>
> >>>> El mar, 13 jul 2021 a las 16:00, Norman Breau ( >)
> >>>> escribió:
> >>>>
> >>>> What Apache maintained plugin uses C/C++ code for android?
> >>>>
> >>>>> On 2021-07-13 10:44 a.m., Jesse wrote:
> >>>>> Cordova has plenty of native code, users just don’t need to write
> any.
> >>>>>
> >>>>>
> >>>>>> On Jul 13, 2021, at 5:27 AM, Norman Breau 
> >>>> wrote:
> >>>>>> I don't think Cordova has any native code whatsoever, so I don't
> >> think
> >>>> this is really relevant to Cordova.
> >>>>>> This might be caused by a plugin that needs to compile/import native
> >>>> code, in which case the solution seems to be to install version
> >>>> 21.0.6113669 instead of 22.1.7171670. If this is the case, it would be
> >> up
> >>>> to the user (or the plugin author, if they decide to take
> >> responsibility)
> >>>> to ensure that the environment is configured in a way that it will
> work
> >>>> with that plugin.
> >>>>>>> On 2021-07-12 11:45 p.m., Chris Brody wrote:
> >>>>>>> Hello I just encountered this after having reinstalled my system on
> >>>> macOS,
> >>>>>>> installing recent NDK via Android Studio:
> >>>&g

Re: [Cordova dev] Task :app:stripDebugDebugSymbols / No version of NDK matched [...]

[julio cesar sanchez]

Jesse, Norman means NDK code, which is considered native (stands for Native
Development Kit).
We don't have any of those.
We have plenty of java code, but that's not affected by the NDK.

El mar, 13 jul 2021 a las 16:00, Norman Breau ()
escribió:

> What Apache maintained plugin uses C/C++ code for android?
>
> On 2021-07-13 10:44 a.m., Jesse wrote:
> > Cordova has plenty of native code, users just don’t need to write any.
> >
> >
> >> On Jul 13, 2021, at 5:27 AM, Norman Breau 
> wrote:
> >>
> >> I don't think Cordova has any native code whatsoever, so I don't think
> this is really relevant to Cordova.
> >>
> >> This might be caused by a plugin that needs to compile/import native
> code, in which case the solution seems to be to install version
> 21.0.6113669 instead of 22.1.7171670. If this is the case, it would be up
> to the user (or the plugin author, if they decide to take responsibility)
> to ensure that the environment is configured in a way that it will work
> with that plugin.
> >>
> >>> On 2021-07-12 11:45 p.m., Chris Brody wrote:
> >>> Hello I just encountered this after having reinstalled my system on
> macOS,
> >>> installing recent NDK via Android Studio:
> >>>
> >>> Starting a Gradle Daemon (subsequent builds will be faster)
> >>>
> >>> *> Task :app:stripDebugDebugSymbols* FAILED
> >>>
> >>>
> >>> FAILURE: Build failed with an exception.
> >>>
> >>>
> >>> * What went wrong:
> >>>
> >>> Execution failed for task ':app:stripDebugDebugSymbols'.
> >>>
>  No version of NDK matched the requested version 21.0.6113669. Versions
> >>> available locally: 22.1.7171670
> >>>
> >>> already found a couple of resources:
> >>>
> >>> -
> >>>
> https://stackoverflow.com/questions/60404457/no-version-of-ndk-matched-the-requested-version
> >>> - https://www.programmersought.com/article/38846032343/
> >>>
> >>> I hope we can find a better solution. Here is what I get from React
> Native,
> >>> for example:
> >>>
> >>> *> Task :app:stripDebugDebugSymbols*
> >>>
> >>> Unable to strip the following libraries, packaging them as they are:
> >>> libc++_shared.so, libevent-2.1.so, libevent_core-2.1.so,
> >>> libevent_extra-2.1.so, libfb.so, libfbjni.so, libflipper.so,
> >>> libfolly_futures.so, libfolly_json.so, libglog.so, libglog_init.so,
> >>> libhermes-executor-common-debug.so,
> libhermes-executor-common-release.so,
> >>> libhermes-executor-debug.so, libhermes-executor-release.so,
> >>> libhermes-inspector.so, libimagepipeline.so, libjsc.so,
> libjscexecutor.so,
> >>> libjsijniprofiler.so, libjsinspector.so, libnative-filters.so,
> >>> libnative-imagetranscoder.so, libreact_codegen_reactandroidspec.so,
> >>> libreact_nativemodule_core.so, libreactnativeblob.so,
> libreactnativejni.so,
> >>> libreactnativeutilsjni.so, libreactperfloggerjni.so,
> >>> libturbomodulejsijni.so, libyoga.so.
> >>>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >> For additional commands, e-mail: dev-h...@cordova.apache.org
> >>
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [DISCUSS] Moving forward with the WebView on AndroidX and cordova-android 10

[julio cesar sanchez]

My understanding is that file urls can technically continue working,
but the defaults changed and some settings need to be enabled, and
some of them are now deprecated and will stop working at some point in
the future.

I think defaulting to the old behavior is ok when doing minor releases
(not just on, but enforced because otherwise it’s a breaking change),
but whenever we make a major release, we should always use the new
behavior and make the cordova user responsibility to enable the old
behavior if they need it, because to not “break” existing apps we will
make all new apps to face the same problem in the future.

About the data loss, the data is not really lost, the data is still
there, but since the scheme and hostname change it’s not accesible
anymore, so if the cordova users can enable the old behavior they’ll
get the data back and should be their responsibility to do so if
needed and do it before releasing a new version. We should of course
warn about it so they will be aware if they read the release blog post
or change log.

If cordova does the data migration is when we can screw up and do it
wrong and cause the massive data loss for all users, I prefer to not
put that responsibility into the project. You have not tried to do it
in your own apps because it’s risky, would you be confident to do it
for all users?

2021-04-27 21:15 GMT+02:00, Darryl Pogue :
> To counter a bit, all of my apps are using the standard Cordova
> Android WebView, and store all their data in the browser's indexedDB.
> I've had no issues with file URLs (although I expect that will change
> with API 30 enforcement).
>
> Losing data in an app update is unacceptable, and for many apps it
> would be catastrophic (see comments from when Google did a bad
> indexedDB migration and people lost data[1]). On iOS with WKWebView,
> I'm stuck in the position of continuing to use file URLs to keep
> existing data working because there's no supported path for data
> migration to the new scheme.
>
> We made the decision with Cordova iOS to use file URLs by default to
> ensure that we didn't unexpectedly break existing apps.
>
> We either need to default to using file URLs on Android (which is
> risky considering the API 30 enforcement is restricting what works
> there), or provide an officially supported update path that preserves
> and migrates all the relevant data. (If we opt for the migration path,
> it would be nice to have it support iOS as well.)
>
> If we release a Cordova update that causes a bunch of existing Android
> apps to lose all their data, it will very likely be a public image
> disaster from which we will never recover.
>
> [1] https://bugs.chromium.org/p/chromium/issues/detail?id=1033655
>
> On Tue, Apr 27, 2021 at 8:48 AM Bryan Ellis  wrote:
>>
>> I also agree.
>>
>> I think we should move forward with these changes and use the
>> WebViewAssetLoader by default.
>>
>> If must, we could write a blog post explaining how to use Norman's plugin
>> for data migration. But I do not know if the plugin is complete to cover
>> all data sources and fits this case.
>>
>> I believe the change though is necessary.
>>
>> Starting from API 30, Google has disabled file access to the WebView
>> because it introduces possible security risks.
>>
>>  > Apps should not open file:// URLs from any external source in WebView,
>> don't enable this if your app accepts arbitrary URLs from external
>> sources.
>>
>> In our recent release of Cordova-Android, we explicitly set the
>> `setAllowFileAccess` to `true` to get around the change that came in the
>> API 30 release. This allowed apps to continue working temporarily, while
>> we would introduce a proper solution in this coming major release,
>> preferably following a secure implementation. I believe we should not
>> default to something that has been publicly announced and known to lead to
>> potential security risks.
>>
>> If we want to support the file scheme to allow users to avoid data loss, I
>> think a config.xml flag can be introduced that users can manually set if
>> they are willing to accept the potential security risks that exist with
>> it. And it could allow them to move over whenever they decide.
>>
>>
>>
>> > On Apr 27, 2021, at 9:07 PM, julio cesar sanchez
>> >  wrote:
>> >
>> > I would vote for defaulting to WebViewAssetLoader but still allow using
>> > file:// from a config.xml preference for the people that are not ready
>> > to
>> > move on.
>> > But on cordova-ios 6 I think we ended up defaulting to file:// and use
>> > the
>> > schemes only as opt-in.
>> >
>> > About m

Re: [DISCUSS] Moving forward with the WebView on AndroidX and cordova-android 10

[julio cesar sanchez]

I would vote for defaulting to WebViewAssetLoader but still allow using
file:// from a config.xml preference for the people that are not ready to
move on.
But on cordova-ios 6 I think we ended up defaulting to file:// and use the
schemes only as opt-in.

About migrating data, I don't think that's our job, but we can point users
to plugins if you know some.

El mar, 27 abr 2021 a las 8:03, Niklas Apache ()
escribió:

> Hey folks,
>
> we recently merged a PR [1] which significantly changes how cordova-
> android loads web content in the webview and now need to decide how to
> move proceed.
>
> Google introduced the WebViewAssetLoader to make it possible to use web
> content from a standard http(s) scheme instead of file:. This was done
> to remove security risks [2] and some apps with routing frameworks like
> React and Angular need this for proper routing.
>
> Because cordova-android 10 now uses AndroidX we could implement the
> WebViewAssetLoader and remove some deprecated or security related
> WebSettings and move the platform forward to current Android standards.
>
> This change may break some apps now because the origin changes if the
> app now runs on https://localhost for example instead of file://.
> Changing the origin means losing access to web storage like
> localstorage, indexedb etc. First and foremost we need to announce that
> change with the release for developers to act but additionally we could
> do:
>
> 1.) Default back to file:// and make the WebViewAssetLoader opt-in via
> config.xml. This exposes apps to the security risk:
>
> > Note: Apps should not open file:// URLs from any external source in
> WebView, don't enable this if your app accepts arbitrary URLs from
> external sources. It's recommended to always use
>  androidx.webkit.WebViewAssetLoader
> <
> https://developer.android.com/reference/androidx/webkit/WebViewAssetLoader
> >
> to access files including assets and resources over http(s):// schemes,
> instead of file:// URLs. To prevent possible security issues targeting
> Build.VERSION_CODES.Q
> 
> and earlier, you should explicitly set this value to false.
>
> 2.) Add a migration for localstorage etc. to the platform to provide a
> smoother transition
>
> 3.) Use the WebViewAssetLoader only and don't migrate in the platform
> but point users to a plugin that helps them to manage their migration
>
> Personally I would favor to move to WebViewAssetLoader by default in
> this breaking release to get apps up to date and adapt to Androids
> changes. I don't know how many apps would be affected because I suspect
> many apps are using native storage solutions (SQLite etc.) or are
> running Ionics WebView with the https scheme already. I am doing both
> for my apps because of the many localstorage and non https scheme issues
> we had in the past and I suspect many did as well.
>
> Cordova Android 10 needs to be released rather sooner than later so
> please leave your feedback.
>
> Thank you very much and kind regards
> Niklas
>
> [1] https://github.com/apache/cordova-android/pull/1137
> [2]
>
> https://developer.android.com/reference/android/webkit/WebSettings#setAllowFileAccess(boolean)
>

Re: [DISCUSS] deprecate cordova-plugin-whitelist

[julio cesar sanchez]

I don’t think we need a vote for deprecating the plugin since the
integration was voted back on 2017. The deprecation is part of the
integration, so the same vote should be enough.


El El mar, 13 abr 2021 a las 12:49, Bryan Ellis  escribió:

> I would like to start the process of deprecating the Cordova Whitelist
> Plugin.
>
> I have already submitted a PR to Cordova-Android’s repo which integrates
> this plugin as a core feature.
>
> Additionally, during this migration/integration PR, I have also renamed
> this plugin to AllowList.
>
> The Cordova-Android AllowList PR can be found here:
>
> https://github.com/apache/cordova-android/pull/1138 <
> https://github.com/apache/cordova-android/pull/1138>
>
>
> Before we can merge in the Cordova-Android's PR, we should first merge in
> this cordova-plugin-whitelist PR and deprecate it.
>
> https://github.com/apache/cordova-plugin-whitelist/pull/59 <
> https://github.com/apache/cordova-plugin-whitelist/pull/59>
>
>
> The cordova-plugin-whitelist PR does:
>
> 1. It updates the Android engine version range
> restriction. It will prevent this plugin from being installed onto Cordova
> Android 10 and greater and Cordova Android 4 or less.
> 2. Adds all the deprecation notices.
>
>
> Are there any concerns with continuing the deprecation process at this
> moment for this plugin?
>
> I would like to start the vote tomorrow if there are no concerns.
>

Re: [DISCUSS] cordova-android 9.1.0 Minor Release

[julio cesar sanchez]

I've seen that Bryant sent a few PRs reverting gradle related dependencies.
I only meant gradle wrapper, not everything else, and it's because Android
Studio automatically updates to 6.5 instead of updating to the latest
version.
In Capacitor we have had problems when users have updated the wrapper, but
not with the gradle plugin or google services plugin (at least that I
remember)


El mié, 31 mar 2021 a las 2:57, Jesse () escribió:

> +1 to moving ahead with 9.1.0, I think this is correctly identified as a
> minor.
>
>
> On Tue, Mar 30, 2021 at 2:51 PM  wrote:
>
> > It would be great if we could include
> > https://github.com/apache/cordova-android/pull/1101 in this release.
> >
> > It is just a pure refactoring/non-functional change PR but it sure would
> be
> > great to merge and release it before it gets stale.
> >
> > I would have no concerns merging it as is, even without reviews, since I
> am
> > confident it is an improvement in code quality. So we would not need to
> > delay the release.
> >
> > What do you think?
> >
> > Bryan Ellis  schrieb am Di., 30. März 2021, 17:06:
> >
> > > Does anyone have any reason to delay a cordova-android minor release
> > > (9.1.0)?
> > >
> > > Any additional outstanding changes to land?
> > >
> > > If not, I will start the release process shortly.
> > >
> > >
> > > ==Changes==
> > >
> > > https://github.com/apache/cordova-android/compare/9.0.0...master
> >
>

Re: [DISCUSS] cordova-android 9.1.0 Minor Release

[julio cesar sanchez]

Yeah, but 9.0.0 was a major release, and the PR that updated gradle had
"major" on the title. So it was safer to bump versions.

El mar, 30 mar 2021 a las 19:49, Chris Brody ()
escribió:

> FYI the build seemed to be red due to a timeout; I just restarted the
> build; hope it will be green.
>
>
> On Tue, Mar 30, 2021 at 1:46 PM Norman Breau 
> wrote:
>
> > 9.0 used the latest available release at the time of the release with no
> > issue. Gradle 6.5 is just the minimum required version according to the
> > docs, they explicitly say 6.5+ is supported:
> > https://developer.android.com/studio/releases/gradle-plugin
> >
> > Because we were already on >= 6.5, I think this is still okay for
> release.
> >
> > On 2021-03-30 2:37 p.m., julio cesar sanchez wrote:
> > > I'm a little concerned about
> > > https://github.com/apache/cordova-android/pull/1174 and the previous
> one
> > > that also bumped the gradle version to 6.6.1. If you open the project
> on
> > > latest Android Studio, Android Studio recommends using Gradle 6.5, so
> not
> > > sure how safe it is to use the latest bleeding edge version instead of
> > the
> > > recommended and if that could cause problems with plugins that have
> > gradle
> > > files.
> > >
> > > But since it's a minor bump maybe I have no reason to be concerned.
> > >
> > > Other than that, looks good.
> > >
> > >
> > > El mar, 30 mar 2021 a las 17:06, Bryan Ellis ()
> > escribió:
> > >
> > >> Does anyone have any reason to delay a cordova-android minor release
> > >> (9.1.0)?
> > >>
> > >> Any additional outstanding changes to land?
> > >>
> > >> If not, I will start the release process shortly.
> > >>
> > >>
> > >> ==Changes==
> > >>
> > >> https://github.com/apache/cordova-android/compare/9.0.0...master
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>

Re: [DISCUSS] cordova-android 9.1.0 Minor Release

[julio cesar sanchez]

I'm a little concerned about
https://github.com/apache/cordova-android/pull/1174 and the previous one
that also bumped the gradle version to 6.6.1. If you open the project on
latest Android Studio, Android Studio recommends using Gradle 6.5, so not
sure how safe it is to use the latest bleeding edge version instead of the
recommended and if that could cause problems with plugins that have gradle
files.

But since it's a minor bump maybe I have no reason to be concerned.

Other than that, looks good.


El mar, 30 mar 2021 a las 17:06, Bryan Ellis () escribió:

> Does anyone have any reason to delay a cordova-android minor release
> (9.1.0)?
>
> Any additional outstanding changes to land?
>
> If not, I will start the release process shortly.
>
>
> ==Changes==
>
> https://github.com/apache/cordova-android/compare/9.0.0...master

Re: Cordova plan to adopt LivePerson Messaging SDK?

[julio cesar sanchez]

We don't create apache plugins for 3rd party SDKs, you can build it
yourself or contact Liveperson and ask them about a plugin.


El mié, 3 mar 2021 a las 10:08, Manisha Bardiya ()
escribió:

> Hi Team,
>
> We are looking at Cordova as an option for our mobile app, can you confirm
> if you have any plans to adopt native Liveperson Messaging SDK in Cordova?
> If yes, May I know your planned timelines, this will help us a lot.
>
> Thanks in advance.
>
>
>
> Thanks,
>
> Manisha Bardiya
>

Re: [VOTE] Deprecate cordova-plugin-wkwebview-engine

[julio cesar sanchez]

+1

El sábado, 6 de febrero de 2021, Niklas Apache 
escribió:

> +1
>
> On February 6, 2021, "dpogue.ca"  wrote:
> > +1
> >
> > On Fri, Feb 5, 2021 at 8:54 PM Bryan Ellis  wrote:
> > >
> > > +1
> > >
> > > On Sat, Feb 6, 2021 at 1:21 PM Jesse 
> > wrote:
> > >
> > > > +1
> > > >
> > > > > On Feb 5, 2021, at 5:49 PM, Norman Breau 
> > wrote:
> > > > >
> > > > > Now that the wkwebview engine plugin is published on NPM,
> > pending
> > > > announcement (waiting for cordova.apache.org to update with the
> > blog
> > > > post). I would like to set motion a vote to deprecate this
> > package.
> > > > >
> > > > > The reason for deprecation is the plugin's code base has
> > effectively
> > > > been moved to the core cordova-ios platform, making the plugin
> > deprecated.
> > > > >
> > > > > Upon a successful vote to deprecate this plugin, I'll prepare a
> > PR
> > > > adding deprecation text to the plugin's readme as well as marking
> > the NPM
> > > > package as deprecated.
> > > > >
> > > > > I vote +1.
> > > > >
> > > > >
> > > > >
> > > > >
> > -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > > > >
> > > >
> > > >
> > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > > >
> > > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
>

Re: [DISCUSS] Cordova Plugin Geolocation 4.1.0 Release

[julio cesar sanchez]

Variables have always required to uninstall and reinstall to change them.

El lunes, 9 de noviembre de 2020, Bryan Ellis  escribió:

> I also agree that this issue is not related to the plugin and should not be
> a blocker for the release.
>
> With little digging into this issue, I want to say it might be an issue in
> Cordova Lib and maybe around munger.
>
> When you add the plugin, and review the contents of this file:
> */cordovaPlugin/platforms/android/android.json,
> y*ou will notice that it contains plugin information which I want to say is
> going to be used for the cordova prepare step.
>
> Example snippet:
>
> "cordova-plugin-geolocation": {
>   "GPS_REQUIRED": "false",
>   "PACKAGE_NAME": "org.apache.cordovaPlugin"
> }
>
> When running cordova prepare, this is not updated either.
>
> More investigation would be required to determine if it is coming from
> this, and also another thread to future discuss this issue and also if it
> is intentional or not.
>
>
>
> On Mon, Nov 9, 2020 at 3:34 PM Norman Breau  wrote:
>
> > Testing the feature that was added, I observed some odd behaviour.
> >
> > I added the plugin with the --variable GPS_REQUIRED set to false. This
> > works as expected, with the variable recorded in package.json and the
> > AndroidManifest.xml containing the proper flag to signal that gps
> hardware
> > is not required.
> > However, if I change the variable inside package.json from "false" to
> > "true" and rerun prepare or build, the AndroidManifest.xml is not
> updated.
> > The only way I can get AndroidManifest.xml to update properly is by
> > removing the plugin and re-adding it with the updated variable. Is this
> > intentional?
> > Even if this is a bug, I don't think it's a bug inside this plugin so I
> > don't think it's necessary to block the release or anything. Just simply
> > pointing out a potential problem.
> > On Nov 5 2020, at 11:32 pm, Bryan Ellis  wrote:
> > >
> > > This is an updated thread of the previous thread
> > https://lists.apache.org/thread.html/r431cbb7ae688285280e2cb0a92f88
> c241596960c0932c34ca45bd7b7%40%3Cdev.cordova.apache.org%3E
> > <
> > https://lists.apache.org/thread.html/r431cbb7ae688285280e2cb0a92f88
> c241596960c0932c34ca45bd7b7@%3Cdev.cordova.apache.org%3E
> > >
> > > The only exception is that it will prepare for the
> > cordova-plugin-geolocation 4.1.0 release instead.
>

Re: Proxy for CORS/ITP issues built into cordova-ios

[julio cesar sanchez]

I don't think the proxy belongs to cordova-ios, I think it should be a
separate plugin, but not a webview plugin, I think cordova-ios should allow
one this two:

a) cordova-ios should allow plugins/users to set their
own WKURLSchemeHandler. This can be problematic since there can only be one
for the same scheme, so should be a subclass of CDVURLSchemeHandler or
duplicate most of its code.
b) cordova-ios should allow plugins to handle requests
inside CDVURLSchemeHandler, so if a plugin is able to handle a request, let
the plugin handle it, if not, use the default CDVURLSchemeHandler code for
request handling.

Both options would allow to create plugins that act like a proxy, or other
features like loading app content from the device file system instead of
from the www folder (for live update plugins).

El mar., 13 oct. 2020 a las 13:43, Niklas Merz ()
escribió:

> This might take time to get released in Cordova iOS if it becomes part of
> the platform at all.
>
> On 2020/10/08 21:22:08, Steve Podell  wrote:
> > Hi,
> >I desperately need this for the non-profit WeVote Voter Guide app
> > .  Please add your change to cordova IOS, it
> > seems like a core feature for IOS 14 to me.
> >
>
> If you need an solution immediatly you can use a custom version of the
> Ionic Webview plugin:
> cordova plugin add
> https://github.com/GEDYSIntraWare/cordova-plugin-ionic-webview#custom.
> Contact me if you need help.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [DISCUSS] Cordova Plugin Geolocation 4.0.3 Release

[julio cesar sanchez]

It should be 4.1.0

One of the changes adds a new install variable, that's a feature.

El jue., 5 nov. 2020 a las 17:14, Bryan Ellis () escribió:

> Does anyone have any reason to delay a cordova-plugin-geolocation release
> 4.0.3?
>
> Any additional outstanding changes to land?
>
> If not, I will start the release process with <= 24 hours.

Re: Minimum Target SDK

[julio cesar sanchez]

Related to this. Should we allow setting the min SDK lower than the min SDK
cordova-android uses?
At the moment it’s not possible, I closed this issue because I thought we
didn’t allow it, but if we allow it then should be reopened and fixed

https://github.com/apache/cordova-android/issues/1070

El jueves, 15 de octubre de 2020, Norman Breau 
escribió:

> To recap our hangouts meeting on this topic
>
> Sounds like the stance we are to take is to officially only support the
> cordova default target/compile sdk version (which is currently 29). Users
> can change this if they wish at their own risk.
> Norman Breau
> Software Developer
>
> nor...@normanbreau.com (mailto:nor...@normanbreau.com)
> https://breautek.com
>
> On Oct 15 2020, at 6:05 am, Pieter Van Poyer  portofantwerp.com> wrote:
> >
> > Hi
> >
> >
> > I'd like to give my opinion. Because the discussion about the sdk
> version was with me.
> >
> > I don't like to disagree with Norman, but the problem with the
> CameraPlugin was IMO not with the targetSdkVersion. I could lower the
> targetSdkVersion to 22 without any problems.
> >
> > The problem was with the compileSdkVersion.
> > I was not able to use a constant available in android 28
> (Build.VERSION_CODES.P, if I am right), because Norman suggested it would
> be able to compile with android level 22.
> > So I did change it to the numerical 28 .
> >
> >
> >
> >
> >
> >
> > So IMO, there may be more guidelines
> > About the targetSdkVersion. Not sure about that one. (
> https://developer.android.com/guide/topics/manifest/uses-
> sdk-element.html#target )
> > About the compileSdkVersion (only support officially the one used for
> cordova-android – 29).
> > With using the latest compileSdkVersion and skipping the previous (now
> 22 – 28), plugin developers can use the features from api 29.
> >
> >
> >
> >
> > And for a plugin, this settings must indeed be based on the supported
> cordova (-android) version of that plugin. It must indeed be able to run on
> the defaultMinSdkVersion for the supported cordova-android versions.
> >
> > Kind regards
> > Pieter Van Poyer
> >
> > -Oorspronkelijk bericht-
> > Van: julio cesar sanchez 
> > Verzonden: donderdag 15 oktober 2020 00:39
> > Aan: dev@cordova.apache.org
> > Onderwerp: Re: Minimum Target SDK
> >
> >
> >
> > Despite we allow users to configure the target SDK, I don’t think we
> should allow other than the default on latest cordova-android.
> >
> > By allow I mean on issues, users are free to use whatever they want, but
> if they don’t use latest they should take care of possible problems
> themselves.
> > With that being said, camera plugin requires latest cordova-android, so
> that means target sdk 29.
> >
> > But also we need to have in mind that if the plugin allowed older
> cordova-android versions and we add some code that requires a higher sdk
> than the default on that cordova-android version we should bump the
> dependency to the version that targets that sdk as default.
> >
> > BTW, sdk 29 is already a requirement for new apps since August, November
> is for existing apps.
> >
> > El El mié, 14 oct 2020 a las 23:46, Norman Breau  (mailto:nor...@normanbreau.com)>
> > escribió:
> >
> > > Hi team,
> > >
> > > A recent discussion came up about what the minimum Target SDK we
> > > should support. Google enforces apps to be built with at least Target
> > > SDK 28 (soon to be 29 coming November), but Cordova users may not be
> > > publishing to the Google Play store, particularly with enterprise
> > > businesses with internal distribution systems.
> > > This is currently not documented and I would like it to be documented
> > > because we were close to merging a PR that would make the camera
> > > plugin require Target SDK 28. But before I submit a documentation PR I
> > > would like some feedback on what our minimum Target SDK should be.
> > > Logically I think it makes the most sense to say that whatever what
> > > our Minimum SDK level is should be our minimum supported Target SDK
> > > (which is currently 22 for cordova-android@9).
> > > For clarity because terminology here is a little confusion:
> > > Minimum SDK = The minimum supported OS Target SDK = The SDK level used
> > > to compile an app.
> > >
> > > Norman Breau
> > > Software Developer
> > >
> > > nor...@normanbreau.com (mailto:nor...@normanbreau.com) (
> > > https://eur0

Re: Minimum Target SDK

[julio cesar sanchez]

Despite we allow users to configure the target SDK, I don’t think we should
allow other than the default on latest cordova-android.

By allow I mean on issues, users are free to use whatever they want, but if
they don’t use latest they should take care of possible problems themselves.
With that being said, camera plugin requires latest cordova-android, so
that means target sdk 29.

But also we need to have in mind that if the plugin allowed older
cordova-android versions and we add some code that requires a higher sdk
than the default on that cordova-android version we should bump the
dependency to the version that targets that sdk as default.

BTW, sdk 29 is already a requirement for new apps since August, November is
for existing apps.

El El mié, 14 oct 2020 a las 23:46, Norman Breau 
escribió:

> Hi team,
>
> A recent discussion came up about what the minimum Target SDK we should
> support. Google enforces apps to be built with at least Target SDK 28 (soon
> to be 29 coming November), but Cordova users may not be publishing to the
> Google Play store, particularly with enterprise businesses with internal
> distribution systems.
> This is currently not documented and I would like it to be documented
> because we were close to merging a PR that would make the camera plugin
> require Target SDK 28. But before I submit a documentation PR I would like
> some feedback on what our minimum Target SDK should be.
> Logically I think it makes the most sense to say that whatever what our
> Minimum SDK level is should be our minimum supported Target SDK (which is
> currently 22 for cordova-android@9).
> For clarity because terminology here is a little confusion:
> Minimum SDK = The minimum supported OS
> Target SDK = The SDK level used to compile an app.
>
> Norman Breau
> Software Developer
>
> nor...@normanbreau.com (
> https://link.getmailspring.com/link/c6cac914-84d1-430d-9fd4-acd8f2bcd...@getmailspring.com/0?redirect=mailto%3Anorman%40normanbreau.com=ZGV2QGNvcmRvdmEuYXBhY2hlLm9yZw%3D%3D
> )
> https://breautek.com (
> https://link.getmailspring.com/link/c6cac914-84d1-430d-9fd4-acd8f2bcd...@getmailspring.com/2?redirect=https%3A%2F%2Fbreautek.com=ZGV2QGNvcmRvdmEuYXBhY2hlLm9yZw%3D%3D
> )
>
>

Re: Greenfield for cordova-plugin-network-information + release version 3.0.0

[julio cesar sanchez]

It would be good that instead of just saying what you would like to see
changed, you also say why you would like it (benefits, reasoning, etc.)

El lunes, 7 de septiembre de 2020, Niklas Merz 
escribió:

> Hi Pieter
>
> At first a warm welcome to the list.
>
> If you would like to open a proposal for discussion I can point you to
> the cordova-discuss repository:
> https://github.com/apache/cordova-discuss/ . We track some proposals in
> issues and pull requests there.
>
> I am not really familiar with the plugin but looking at the description
> and recent activity it looks like it was designed to implement the old
> version of the Network Information API. Other community members probably
> know more about that.
>
> A new major version could possibly change that if we can get consensus
> about this but someone would need to do the work.
>
> It looks you already got your own requirements ready and I personally
> would build and publish this plugin myself in this case. Creating
> plugins is not that hard if you start with the skeleton of an existing
> one. Contact me if you need any help.
>
> Kind regards
> Niklas
>
> Am 07.09.20 um 00:06 schrieb Pieter Van Poyer:
> > Hey Cordova devs
> >
> > You are doing a great job with Cordova.
> > I've got a question, suggestion for the cordova-plugin-network-
> information.
> >
> > Is it possible to open an issue, a milestone, a metaticket or something
> to discuss the future requirements of the plugin (v4).
> > Something like a whitepaper.
> >
> >
> > My suggestions for a whitepaper are:
> >
> > Loosen the requirements of the plugin to it's barebone's essentials.
> > Requirements
> >
> >   *   Detect online/offline only when the app is active.
> >   *   When online, only detect following types: WIFI, MOBILE
> > Stop with next requirements
> >
> >   *   Detect online/offline when the app is not active.
> >   *   Don't try to detect other network type's beside WIFI and MOBILE.
> >   *   Do not let this plugin support background work like fileupload's
> and datasyncs. Remove it from the doc's.
> >   *   Drop Windows platform support.
> > For android: use the NetworkCallback reference/android/net/ConnectivityManager.NetworkCallback.html> API
> instead of the deprecated Connectivitymanager.
> >
> > Maybe we could take some insparation by looking at the Capacitor plugin
> https://github.com/ionic-team/capacitor-plugins/tree/main/network or
> Flutter plugin.
> >
> >
> > Is it also possible to release version 3.0.0 of the plugin.
> >
> > Kind regards
> >
> > Pieter Van Poyer
> >
> > 
> >
> > Deze e-mail en alle gekoppelde bestanden zijn officiele documenten van
> Havenbedrijf Antwerpen NV van publiek recht en kunnen vertrouwelijke of
> persoonlijke informatie bevatten. Gelieve de afzender onmiddellijk via
> e-mail of telefonisch te verwittigen als u deze e-mail per vergissing heeft
> ontvangen en verwijder vervolgens de e-mail zonder deze te lezen, te
> reproduceren, te verspreiden of te ontsluiten naar derden. Havenbedrijf
> Antwerpen NV van publiek recht is op geen enkele manier verantwoordelijk
> voor fouten of onnauwkeurigheden in de inhoud van deze e-mail. Havenbedrijf
> Antwerpen NV van publiek recht kan niet aansprakelijk gesteld worden voor
> directe of indirecte schade, verlies of ongemak veroorzaakt als gevolg van
> een onnauwkeurigheid of fout in deze e-mail.
> >
> > English Translation: This e-mail and all attached files are official
> documents of Antwerp Port Authority and may contain confidential or
> personal information. If you have received this e-mail in error, you are
> asked to inform the sender by e-mail or telephone immediately, and to
> remove it from your system without reading or reproducing it or passing it
> on to other parties. Antwerp Port Authority is in no way responsible for
> any errors or inaccuracies in the contents of this e-mail, nor can it be
> held liable for any direct or indirect loss, damage or inconvenience
> arising from any such errors or inaccuracies.
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: PhoneGap Plugins?

[julio cesar sanchez]

The push plugin is already forked and got a few code updates, so if you
could point to it in the phonegap one would be good. Will have a different
name, so people will have to replace it.

For the barcode, the aar used on android is 4 year old and it’s built from
a zxing app that was abandoned 2 years ago and that was very hard to
update, so I don’t think it makes sense to continue maintaining it as is.
Nowadays there are better sdks, so would make more sense a completely new
plugin, but doesn’t need to be on the Apache umbrella.

El viernes, 4 de septiembre de 2020, Simon MacDonald <
simon.macdon...@gmail.com> escribió:

> Yeah, no worries folks. If you don't have the bandwidth to pull them
> under the Apache umbrella I completely understand.
>
> As for licensing, we'd be able to figure it out. I work with 4 lawyers
> on this stuff so they would be able to figure out a path that works.
>
> Simon Mac Donald
> http://simonmacdonald.com
>
> On Thu, Sep 3, 2020 at 1:45 PM Chris Brody  wrote:
> >
> > At this point I would be a little reluctant to start supporting more
> > plugins.
> >
> > Issues and unmerged PRs seem to keep piling up in multiple places. Here
> are
> > a couple of very sad examples:
> >
> > - https://github.com/apache/cordova-ios/pull/795
> > - https://github.com/apache/cordova-plugin-file/pull/242
> >
> >
> > On Thu, Sep 3, 2020 at 12:34 AM Bryan Ellis  wrote:
> >
> > > It could be integrated into Apache.
> > >
> > > What exactly would the process of integrating look like?
> > >
> > > I suspect it would start with a vote email?
> > >
> > > Since the existing plugin license is MIT, what happens here?  I don't
> know
> > > the rules or process on how we can change the license. I had read that
> > > there were exceptions where we might be able to keep the original
> license
> > > while in Apache. I believe...
> > >
> > > Also, would the old repo be transferred, forked, hard copy?
> > >
> > > If we do this, we could start with "phonegap-plugin-barcodescanner”.
> > >
> > >
> > >
> > > > On Aug 29, 2020, at 5:33, Jesse  wrote:
> > > >
> > > > Thanks Simon
> > > >
> > > > We'll look at this. Erisu appears to already be actively working on
> > > > havesource/cordova-plugin-push
> > > >
> > > > Cheers,
> > > >  Jesse
> > > >
> > > > On Fri, Aug 28, 2020 at 1:22 PM Simon MacDonald <
> > > simon.macdon...@gmail.com>
> > > > wrote:
> > > >
> > > >> Hi folks,
> > > >>
> > > >> Long time no chat. As you are no doubt aware Adobe announced they
> are
> > > >> no longer in the PhoneGap business. To that end I archived the
> > > >> following plugins that are still being used widely:
> > > >>
> > > >> phonegap-plugin-push - 7,659 weekly downloads
> > > >> phonegap-plugin-barcodescanner - 11,058 weekly downloads
> > > >>
> > > >> I'm terribly disappointed that I have not been able to actively
> > > >> maintain them for the past two years. To that end, if you think it
> > > >> would be beneficial to Apache Cordova I can navigate the waters
> > > >> internally to donate the plugins to Apache.
> > > >>
> > > >> Note: I'm not trying to throw this code over the wall and make it
> > > >> someone else's problem. Cordova has been a positive experience in my
> > > >> life and if donating the code helps the project I'll make it happen.
> > > >> If you don't feel like it would help we'll keep the repo's archived
> > > >> and hope the community forks and maintains things.
> > > >>
> > > >> Julio mentioned there is already a fork of the push plugin at
> > > >> https://github.com/havesource/cordova-plugin-push.
> > > >>
> > > >> Let me know what you think as I've been contacted by a few users
> > > already.
> > > >>
> > > >> Simon Mac Donald
> > > >> http://simonmacdonald.com
> > > >>
> > > >> 
> -
> > > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > >> For additional commands, e-mail: dev-h...@cordova.apache.org
> > > >>
> > > >>
> > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Cordova as a monorepo - ??

[julio cesar sanchez]

Maybe it makes more sense for the tooling packages, common, cli, lib, etc,
as they get less issues reported and it's usually more confusing for users
(and me) to report in the proper place as a bug in one of those modules can
be caused by another module. But I would keep platforms and plugins in
separate repos.
Also the monorepo makes it not possible to install from github, I think a
lot of people rely on that for installing unreleased versions (specially
for plugins since there are no nightly versions for them).


El jue., 27 ago. 2020 a las 18:26, Chris Brody ()
escribió:

> Someone had an idea to convert Cordova into a single monorepo. There
> are some very well-known benefits, and it would help us to keep the
> issues and discussions all in one place. Lerna seems to be a nice tool
> to keep things consistent and in sync.
>
> I think the original PhoneGap that Cordova was based on was a kind of
> monorepo, before it was split up.
>
> I generally tend to lean the other way and favor "small, focused
> modules" but just wanted to mention this idea in case it can help lead
> to other ideas.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [DISCUSS] Unarchive & Un-deprecate cordova-plugin-device-orientation

[julio cesar sanchez]

I guess you mean this issue
https://github.com/apache/cordova-plugin-device-orientation/issues/52

To be clear, the web API still works on iOS 13, but it requires to request
a permission first with DeviceMotionEvent.requestPermission();

But the permission request has a few issues that I have noticed and
reported to Apple.

1.- If using file scheme it will show "" instead of the app name on the
permission request (https://bugs.webkit.org/show_bug.cgi?id=213469), and if
using a custom scheme it will show the hostname (localhost by default.

2.- Even if you provide an usage description for motion, it's not shown on
the webview permission request (
https://bugs.webkit.org/show_bug.cgi?id=213467)

3.- The permission is not remembered, if you allow it, on next app launch
you need to request it again (https://bugs.webkit.org/show_bug.cgi?id=213468
)


El mar., 18 ago. 2020 a las 6:56, Bryan Ellis () escribió:

> This discussion is to unarchive & un-deprecate the plugin:
>
>   cordova-plugin-device-orientation
>
> This plugin is now requires because iOS w/ Custom Schemes does provide the
> support necessary to use Web APIs.
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: plugin engines

[julio cesar sanchez]

>  > And I would also like to remove the "protective" engine all plugins have
> that points the next major version to cordova >= 100
>
> +1. I never really understood the rationale behind this. I think it's
> safe to assume that a next plugin major will continue to support the
> cordova cli that it used to support. If it does not, then we can update
> the engines accordingly.
>

The idea was, if a breaking change was introduced that required updating
engines, but we forgot to update the engines, it would prevent the plugin
to install and break user's projects.
But in most cases it ended in cases where breaking changes were introduced,
but they didn't need updating engines and the "protective" entry ended
blocking the plugin install for no reason, so instead of saving us from
trouble, it caused trouble.


>  > So, what I'm proposing is to add engines to all the plugins to require
> at
> least
> cordova 9
> cordova ios 5.1.0
> cordova-android 8.0.0
>
> I think an argument could be made that adding these could be breaking in
> itself and thus warrant a major release, but at the same time, in
> addition to what Julio said, anything pre cordova-android@8 will not be
> accepted by Google Play store due to target API requirements, and the
> same for pre cordova-ios@5.10 because of the wkwebview requirement. So I
> still give a +1 on this.
>

It's not really a breaking change if we replace the existing protective
entry with these new requirements, since the new requirements are only for
the next major release, and won't have any effect until we release a major
version.

Re: Formally deprecate cordova-plugin-wkwebview-engine?

[julio cesar sanchez]

Yeah, I think we can deprecate it since cordova-ios 6 works the same way by
default, but as Darryl said, we should do a last release with the engines
properly configured to not install in cordova-ios 6.

El El vie, 3 jul 2020 a las 20:04, Darryl Pogue 
escribió:

> I don't know that we want to go as far as deprecating it just yet, but
> we should definitely do a release that prevents it from being
> installed with cordova-ios 6 (since it conflicts).
>
> On Fri, Jul 3, 2020 at 10:50 AM Chris Brody  wrote:
> >
> > It would definitely be nice if we don't have to support that plugin any
> > longer, and I think it would be good to archive it as well. My one
> comment
> > is that there should be a very clear guide for people who have to
> continue
> > using the same scheme due to data stored by the web view. A couple of
> > off-topic items that I think are related:
> >
> > I think we should recommend that people consider using native plugins
> such
> > as cordova-plugin-file, SQLite, or something similar for storing
> important
> > data.. I have seen quite a few things such as local storage deleting
> data,
> > IndexedDB eviction, and other things going wrong to trust the WebView to
> > not lose data.
> >
> > I think we should deprecate and archive some other plugins in the near
> > future, due to the support burden, as I proposed in:
> > https://github.com/apache/cordova/issues/185
> >
> >
> > On Fri, Jul 3, 2020 at 1:28 PM Norman Breau 
> wrote:
> >
> > > Hi team,
> > >
> > > I believe previously we decided on a path to deprecate
> > > cordova-plugin-wkwebview-engine, but I wanted
> > > to make sure that is still our stance.
> > >
> > > cordova-ios@6 supports both url schemes and the legacy file scheme,
> > > effectively making the wkwebview engine plugin redundant. Now that
> > > cordova-ios@6 is released, I feel like it's time to formally deprecate
> > > the wkwebview plugin according to our Deprecation Policy[1]
> > >
> > > With that being said, I'm not sure if we also want to archive this
> > > repository. According to the policy, we should archive if:
> > >
> > > "A deprecated repository might also be archived if we don't intend to
> > > provide support of any kind (Issues, Pull Requests, Releases) for this
> > > component any more."
> > >
> > > I feel like this is probably our intention as I think all maintenance
> > > will now be done in cordova-ios going forward, but I want to gather
> some
> > > thoughts on this.
> > >
> > > [1] https://cordova.apache.org/deprecation_policy.html
> > >
> > > Cheers,
> > > Norman
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [DISCUSS] cordova-lib 10.0.0 Major Release

[julio cesar sanchez]

Ah, didn’t know about the deprecated field.

Then yeah, I think we can set them to true at any moment in a minor release
and then totally remove for next major.
We should probably start separate deprecation vote threads for each
platform.

El El vie, 3 jul 2020 a las 20:00, Chris Brody 
escribió:

> I thought it was cordova-lib, which is used by the Cordova CLI, that would
> generate the deprecated platform messages. Just a reminder that the
> platform supported "out of the box" are imported here (with a require
> statement):
>
> https://github.com/apache/cordova-lib/blob/master/src/platforms/platformsConfig.json
>
> I would definitely agree with Julio that we can add and deprecate platforms
> at any time, presumably in a minor or major release of cordova-lib.
>
> I would definitely favor NOT blocking the cordova-lib release. I just hope
> we can follow up and deprecate the outdated cordova-osx & cordova-windows
> platforms in the near future.
>
>
> On Fri, Jul 3, 2020 at 7:24 AM julio cesar sanchez  >
> wrote:
>
> > Does the CLI/lib has something to do with platform deprecation? I mean,
> do
> > we add warnings or something when adding them?
> >
> > As far as I know you can always add any platform as long as it implements
> > the required API, whether is official and maintained or official and
> > deprecated or a 3rd party platform. Deprecated only means we won’t do
> more
> > work on them and we will remove plugins code for those platforms, so I
> > don’t see any reason to block this release. Even if we add warnings, that
> > can be done in a minor release.
> >
> > El El lun, 29 jun 2020 a las 4:05, Chris Brody 
> > escribió:
> >
> > > Thanks. Am I right to assume we can start the deprecation in a minor
> > > release?
> > >
> > >
> > > On Sun, Jun 28, 2020 at 9:32 PM Bryan Ellis  wrote:
> > >
> > > > The pinning for Android, OSX, and iOS will be bumped before release.
> I
> > am
> > > > currently working on that PR.
> > > >
> > > > The deprecation & removal of OSX and Windows pinning from Lib will
> not
> > be
> > > > performed in this release.
> > > >
> > > > An official vote thread will need to be created for each platform in
> > > > question. The browser should also be included.
> > > >
> > > > The Electron and Browser platform is not being released before Lib or
> > > CLI.
> > > >
> > > > A platform major releases are not required to be performed before a
> > major
> > > > release of Lib or CLI. They can be released at any time. Only a
> > > patch/minor
> > > > release of Lib and CLI is needed.
> > > >
> > > >
> > > > > On Jun 29, 2020, at 10:15, Chris Brody 
> > wrote:
> > > > >
> > > > > I think src/platforms/platformsConfig.json should be updated for
> the
> > > > recent
> > > > > cordova-osx & upcoming cordova-android major releases.
> > > > >
> > > > > I would also like to see cordova-osx and cordova-windows deprecated
> > > now,
> > > > > for reasons discussed in another thread:
> > > > >
> > > > > - cordova-osx has outdated platform name (minor) and is missing
> > support
> > > > for
> > > > > pods, and is expected to be not needed once we can resolve the
> issue
> > > with
> > > > > using Catalyst
> > > > > - cordova-windows is not supported by Visual Studio 2019
> > > > > - maintainers seem to be already overloaded by the burden of
> > supporting
> > > > > Cordova on all other platforms
> > > > >
> > > > > And what about cordova-electron & cordova-browser?
> > > > >
> > > > >
> > > > > On Sun, Jun 28, 2020 at 9:03 PM Bryan Ellis 
> > wrote:
> > > > >
> > > > >> Does anyone have any reason to delay a cordova-lib major release
> > > > (10.0.0)?
> > > > >>
> > > > >> Any additional outstanding changes to land?
> > > > >>
> > > > >> If not, I will start the release process shortly.
> > > > >>
> > > > >>
> > -
> > > > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > > >> For additional commands, e-mail: dev-h...@cordova.apache.org
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
>

Re: [DISCUSS] cordova-lib 10.0.0 Major Release

[julio cesar sanchez]

Does the CLI/lib has something to do with platform deprecation? I mean, do
we add warnings or something when adding them?

As far as I know you can always add any platform as long as it implements
the required API, whether is official and maintained or official and
deprecated or a 3rd party platform. Deprecated only means we won’t do more
work on them and we will remove plugins code for those platforms, so I
don’t see any reason to block this release. Even if we add warnings, that
can be done in a minor release.

El El lun, 29 jun 2020 a las 4:05, Chris Brody 
escribió:

> Thanks. Am I right to assume we can start the deprecation in a minor
> release?
>
>
> On Sun, Jun 28, 2020 at 9:32 PM Bryan Ellis  wrote:
>
> > The pinning for Android, OSX, and iOS will be bumped before release. I am
> > currently working on that PR.
> >
> > The deprecation & removal of OSX and Windows pinning from Lib will not be
> > performed in this release.
> >
> > An official vote thread will need to be created for each platform in
> > question. The browser should also be included.
> >
> > The Electron and Browser platform is not being released before Lib or
> CLI.
> >
> > A platform major releases are not required to be performed before a major
> > release of Lib or CLI. They can be released at any time. Only a
> patch/minor
> > release of Lib and CLI is needed.
> >
> >
> > > On Jun 29, 2020, at 10:15, Chris Brody  wrote:
> > >
> > > I think src/platforms/platformsConfig.json should be updated for the
> > recent
> > > cordova-osx & upcoming cordova-android major releases.
> > >
> > > I would also like to see cordova-osx and cordova-windows deprecated
> now,
> > > for reasons discussed in another thread:
> > >
> > > - cordova-osx has outdated platform name (minor) and is missing support
> > for
> > > pods, and is expected to be not needed once we can resolve the issue
> with
> > > using Catalyst
> > > - cordova-windows is not supported by Visual Studio 2019
> > > - maintainers seem to be already overloaded by the burden of supporting
> > > Cordova on all other platforms
> > >
> > > And what about cordova-electron & cordova-browser?
> > >
> > >
> > > On Sun, Jun 28, 2020 at 9:03 PM Bryan Ellis  wrote:
> > >
> > >> Does anyone have any reason to delay a cordova-lib major release
> > (10.0.0)?
> > >>
> > >> Any additional outstanding changes to land?
> > >>
> > >> If not, I will start the release process shortly.
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > >> For additional commands, e-mail: dev-h...@cordova.apache.org
> > >>
> > >>
> >
> >
>

Re: Question about WKWebView Audio

[julio cesar sanchez]

This list is for talking about the development of Apache cordova project,
not for asking questions.

But FYI, it’s a WKWebView bug, supposedly fixed, but unclear if released

https://bugs.webkit.org/show_bug.cgi?id=203293

El viernes, 26 de junio de 2020, Oliver Deng 
escribió:

> Hi Team,
>
>
> currently, I am facing the issue which is about audio in WKWebView. When we
> use the iPhone to open the ionic Cordova app with background music on, then
> the music will suddenly be paused. Do you know how to fix this?
>
>
>
>
>
> Many thanks
> Oliver Deng
>

Re: June board report

[julio cesar sanchez]

How is this calculated?

Issue close rate of 57%:

   - 300 issues opened on GitHub, past quarter
   - 311 issues closed on GitHub, past quarter

311 closed for 300 opened is more than 100%

El El jue, 11 jun 2020 a las 0:29, Jesse  escribió:

> Sorry for the short notice, the June Board Report is due today.
>
> Please review and reply if you have any additions, revisions, or questions.
>
> https://github.com/apache/cordova-apache-board-reports/blob/master/2020/2020-06.md
>
> If it's all good, I'll be submitting it later this evening.
>
> Cheers,
>   Jesse
>

Re: Modernize cordova-android build?

[julio cesar sanchez]

There is a PR to allow any jdk version, we mistakenly thought java 8 was
required for android development, but looks like we were wrong.

https://github.com/apache/cordova-android/pull/928


El lunes, 8 de junio de 2020, Darryl Pogue  escribió:

> On Sun, Jun 7, 2020 at 7:49 PM Chris Brody  wrote:
> >
> > Another thing is that many build systems are now using a Gradle wrapper,
> > while Cordova still needs the Gradle tool to be installed in its search
> > path. This may be related to a nasty-looking issue here:
> > https://github.com/apache/cordova-android/issues/845
>
> I seem to recall that we have to use the system-installed gradle to
> generate our gradle wrapper, because the wrapper depends on a JAR file
> and we're not allowed to distribute JAR files.
>
> Previous mailing list discussion regarding gradle wrapper distribution:
> https://lists.apache.org/thread.html/9fcaf3cd6b22e9cd6d09e17ff5956b
> f661c3560be923f734dcc4450e%401403096149%40%3Cdev.cordova.apache.org%3E
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [DISCUSS] cordova-ios 6.0.0 Major Release

[julio cesar sanchez]

The podspec issue is not breaking, we can publish on next patch or minor
release.

El El vie, 5 jun 2020 a las 22:00, Chris Brody 
escribió:

> Looks like we missed breaking PR #795:
> https://github.com/apache/cordova-ios/pull/795
>
> I just put #795 into new 7.0.0 milestone, along with the podspec issue:
> https://github.com/apache/cordova-ios/issues/887
>
>
> On Wed, May 20, 2020 at 4:13 AM Bryan Ellis  wrote:
>
> > This is a followup, I will be preparing the iOS release this Friday
> (about
> > ~48hrs from now).
> >
> > There are a few remaining PRs that could be merged but requires review,
> > rebasing, etc.
> >
> > IF these PRs are not prepared or merged in by then, they will be dropped
> > from this release and postponed for next major. (sometime maybe mid-2021)
> >
> > PRs:
> >
> > * #851 - breaking: replace shelljs with fs-extra
> >   * https://github.com/apache/cordova-ios/pull/851 <
> > https://github.com/apache/cordova-ios/pull/851>
> >
> > * #859 - refactor: use superspawn
> >   * https://github.com/apache/cordova-ios/pull/859 <
> > https://github.com/apache/cordova-ios/pull/859>
> >   * Requires #851
> >
> > * #860 - breaking: drop q dependency
> >   * https://github.com/apache/cordova-ios/pull/860 <
> > https://github.com/apache/cordova-ios/pull/860>
> >   * Requires #851 & #859
> >
> > * #861 - chore: add package-lock.json
> >   * https://github.com/apache/cordova-ios/pull/861 <
> > https://github.com/apache/cordova-ios/pull/861>
> >   * Preferably merged after #860
> >   * Requires Rebasing after #860
> >
> > * #852 - ci: use github actions
> >   * https://github.com/apache/cordova-ios/pull/852 <
> > https://github.com/apache/cordova-ios/pull/852>
> >   * Requires #861
> >
> > * #790 CB-13143: Integrate and replace SplashScreens with Launch
> Storyboard
> >   * https://github.com/apache/cordova-ios/pull/790 <
> > https://github.com/apache/cordova-ios/pull/790>
> >   * Requires a rebase
> >
> > * #808 - (iOS) Dark mode splashscreen storyboard images
> >   * https://github.com/apache/cordova-ios/pull/808 <
> > https://github.com/apache/cordova-ios/pull/808>
> >   * Preferably merged after #790
> >
> > As for the reaming PRs that were mentioned previously and not listed
> above:
> >
> > > - https://github.com/apache/cordova-ios/pull/823 <
> > https://github.com/apache/cordova-ios/pull/823>
> > * I left a comment asking for additional feed back and a concern with the
> > change.
> > * No reply has been received.
> > * I believe this PR will not make it in this release.
> >
> > > - https://github.com/apache/cordova-ios/pull/763 <
> > https://github.com/apache/cordova-ios/pull/763>
> > * This PR was closed out with out merge.
> > * It has been replaced with #859 & #860
> >
> > > - https://github.com/apache/cordova-ios/pull/454 <
> > https://github.com/apache/cordova-ios/pull/454>* There is a
> > comment/request to wrap the changes with a flag so it doesn’t change the
> > default.
> > * This request was not been completed.
> > * I believe this PR will not make it in this release.
> >
> >
> >
> > > On Apr 19, 2020, at 3:35, Darryl Pogue  wrote:
> > >
> > > I've just merged two very small PRs:
> > > - https://github.com/apache/cordova-ios/pull/615
> > > - https://github.com/apache/cordova-ios/pull/825
> > >
> > > There are some others that would be nice to get in, but require more
> > > testing or more work to finish:
> > > - https://github.com/apache/cordova-ios/pull/823
> > > - https://github.com/apache/cordova-ios/pull/790
> > > - https://github.com/apache/cordova-ios/pull/763
> > > - https://github.com/apache/cordova-ios/pull/454
> > >
> > > On Fri, Apr 17, 2020 at 10:56 PM Bryan Ellis  wrote:
> > >
> > >> Does anyone have any reason to delay a cordova-ios major release
> > (6.0.0)?
> > >>
> > >> Any additional outstanding changes to land?
> > >>
> > >> If not, I will start the release process in the next couple of days.
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > >> For additional commands, e-mail: dev-h...@cordova.apache.org
> > >>
> > >>
> >
> >
>

Re: [DISCUSS] InAppBrowser 4.0.0 major release

[julio cesar sanchez]

As far as I know, the versions are the minimum required to work, not the
minimum supported by the plugin.

But yeah, ideally we could set all of them to recent versions to make sure
people don't use them in very old versions.

For the record, not all plugins have engines or some have but not for all
versions, and really don't know if they properly work.

El jue., 4 jun. 2020 a las 19:40, Chris Brody ()
escribió:

> The whole motivation behind adding the minimum Cordova engine version, in
> the first place, seems to be here:
>
> https://github.com/apache/cordova-plugin-inappbrowser/blob/master/plugin.xml#L33
>
> It says "Needs cordova/urlutil".
>
> I think we do not specify the minimum Cordova engine version on most of the
> plugins, unfortunately don't have much time to check this right now.
>
> Whenever we do specify a minimum Cordova engine version, I would favor
> specifying a version that is not excessively old such as 6 or 7. This is
> analogous to the Node.js ecosystem where the node field in engines does
> actually specify the minimum Node version it can work with.
>
> But yes, definitely should not update with the current Cordova version.
>
> Yeah, probably not worth blocking a release. I wish I had more time to help
> with this kind of improvement.
>
>
> On Thu, Jun 4, 2020 at 1:20 PM Niklas Merz  wrote:
>
> > Correct me if I am wrong, but I don't think we want to update the
> > dependency versions to the current ones. It's just another version we
> > have to track and update.
> >
> > I must say I don't really know what they are for and would love to learn
> > about that.
> >
> > The PR updates them to be consistent and working with a bare minimum
> > like said in the PR with code checks. These old version numbers don't
> > mean that these version have to be supported and compatible. If users
> > have I issues we always advise to use the latest versions of everything.
> >
> > IMHO this shouldn't block a release.
> >
> > Am 04.06.20 um 17:14 schrieb Chris Brody:
> > > I would favor updating the minimum Cordova requirement in both
> > package.json
> > > and plugin.xml, as I just commented in PR #685. I wish I would have
> seen
> > it
> > > before PR #685 was merged.
> > >
> > >
> > > On Thu, Jun 4, 2020 at 10:59 AM Niklas Merz 
> > wrote:
> > >
> > >> I merged two outstanding patches just now.
> > >>
> > >> If no reviews or concern come up, I will start the release in a few
> > hours.
> > >>
> > >> June 2, 2020 8:31 PM, "Niklas Merz"  wrote:
> > >>
> > >>> Hi all,
> > >>>
> > >>> since cordova-ios 6.0 was released recently the inappbrowser plugin
> > does
> > >> not work properly because
> > >>> of the removal of UIWebView. I would suggest we do a plugin *release
> as
> > >> soon as possible*.
> > >>>
> > >>> Since we already merged some major changes (including the UIWebview
> > >> removal) this will be a major
> > >>> release.
> > >>>
> > >>> Does anyone have a reason to delay the release?
> > >>>
> > >>> From my personal use of the plugin to pending PRs would be helpfull
> for
> > >> this release, but they need
> > >>> reviews. I would not delay the release for them and proceed without
> > >> merging them.
> > >>> https://github.com/apache/cordova-plugin-inappbrowser/pull/688
> > >>> https://github.com/apache/cordova-plugin-inappbrowser/pull/656
> > >>>
> > >>> Any other outstanding patches to land?
> > >>>
> > >>> If not, I will start the release tomorrow.
> > >>>
> > >>> -
> > >>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > >>> For additional commands, e-mail: dev-h...@cordova.apache.org
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > >> For additional commands, e-mail: dev-h...@cordova.apache.org
> > >>
> > >>
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>

Re: Strongly deprecating the FileTransfer plugin

[julio cesar sanchez]

I think people knew they were leaving the project and voted to deprecate
plugins to leave less things to maintain to the few remaining people.

Since there are new committers now that didn’t vote, maybe we can
reconsider/re vote.



El miércoles, 3 de junio de 2020, Darryl Pogue 
escribió:

> Not that we want to outright endorse 3rd party plugins without due
> diligence, but there are other options than the FileTransfer plugin, such
> as https://www.npmjs.com/package/cordova-plugin-advanced-http
>
> On Wed, Jun 3, 2020 at 1:46 PM Tim Brust  wrote:
>
> > While I agree that we should somehow archive old code, I'm still -1 on a
> > deprecation of this plugin. (We've had some discussion about it here,
> too:
> > https://github.com/apache/cordova/issues/185)
> > XHR is not reliable and causes OOM errors when handling large data.
> >
> >
> >
> > On Wed, Jun 3, 2020 at 7:29 PM Norman Breau 
> > wrote:
> >
> > > +1 on archiving/adding  [DEPRECATED] text in the description.
> > >
> > > On 2020-06-03 4:25 p.m., julio cesar sanchez wrote:
> > > > This happens with all the deprecated plugins we have, people keeps
> > > > reporting issues on them.
> > > > I proposed long ago to archive them, but some people was against it,
> > but
> > > I
> > > > think archiving is the way to go when something is deprecated.
> > > >
> > > >
> > > > El miércoles, 3 de junio de 2020, Jesse 
> > > escribió:
> > > >
> > > >> +1 The deprecation notice needs to be prominent, I missed it myself
> > on a
> > > >> quick scroll.
> > > >> Some of that readme is in a specific format to support appearance in
> > > >> docs.cordova.io ( similar to
> > > >> https://cordova.apache.org/docs/en/latest/reference/
> > > >> cordova-plugin-file/index.html
> > > >>   )
> > > >> This is no longer a requirement, so we can go prominent.
> > > >> We should also ask INFRA to put the text [DEPRECATED] in the
> > > description,
> > > >> and possibly even archive the repo.
> > > >>
> > > >>
> > > >> On Wed, Jun 3, 2020 at 12:02 PM Norman Breau <
> nor...@normanbreau.com>
> > > >> wrote:
> > > >>
> > > >>> I'm sure you're not the only one who misses it, considering the
> repo
> > is
> > > >>> still pretty active in terms of new issues being reported.
> > > >>>
> > > >>> On 2020-06-03 3:59 p.m., Darryl Pogue wrote:
> > > >>>> Correction: There is in fact a deprecation notice, part-way down
> the
> > > >>>> README, but it's not especially attention grabbing and I missed it
> > the
> > > >>>> first 2 times I skimmed the file.
> > > >>>>
> > > >>>> On Wed, Jun 3, 2020 at 11:55 AM Darryl Pogue 
> > > wrote:
> > > >>>>
> > > >>>>> Hey folks,
> > > >>>>>
> > > >>>>> The File Transfer plugin has been officially deprecated since
> 2017:
> > > >>>>>
> > > >>> https://cordova.apache.org/blog/2017/10/18/from-
> > > >> filetransfer-to-xhr2.html
> > > >>>>> However, the repo and npm have no link to that page or any sort
> of
> > > >>>>> indication that it is not maintained.
> > > >>>>>
> > > >>>>> With the release of cordova-ios 6, the FileTransfer plugin no
> > longer
> > > >>>>> compiles on iOS:
> > > >>>>> https://github.com/apache/cordova-plugin-file-transfer/
> issues/258
> > > >>>>>
> > > >>>>> I want to reply to that issue saying that it's deprecated and not
> > > >>>>> maintained, but I feel like we haven't made that very clear.
> > > >>>>>
> > > >>>>> I would like to propose that we update the README for File
> Transfer
> > > >>> with a
> > > >>>>> clear deprecation notice which links to the blog post from 2017,
> > and
> > > >>> that
> > > >>>>> we ask ASF Infra to mark the repo as archived.
> > > >>>>>
> > > >>>>> Any objections?
> > > >>>>>
> > > >>>>> ~Darryl
> > > >>>>>
> > > >>> 
> -
> > > >>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > >>> For additional commands, e-mail: dev-h...@cordova.apache.org
> > > >>>
> > > >>>
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> > >
> >
> > --
> > Tim Brust
> > timbrust3...@gmail.com
> >
> > M: +49 160 9757 3632 <+4916097573632>
> >
>

Re: Strongly deprecating the FileTransfer plugin

[julio cesar sanchez]

This happens with all the deprecated plugins we have, people keeps
reporting issues on them.
I proposed long ago to archive them, but some people was against it, but I
think archiving is the way to go when something is deprecated.


El miércoles, 3 de junio de 2020, Jesse  escribió:

> +1 The deprecation notice needs to be prominent, I missed it myself on a
> quick scroll.
> Some of that readme is in a specific format to support appearance in
> docs.cordova.io ( similar to
> https://cordova.apache.org/docs/en/latest/reference/
> cordova-plugin-file/index.html
>  )
> This is no longer a requirement, so we can go prominent.
> We should also ask INFRA to put the text [DEPRECATED] in the description,
> and possibly even archive the repo.
>
>
> On Wed, Jun 3, 2020 at 12:02 PM Norman Breau 
> wrote:
>
> > I'm sure you're not the only one who misses it, considering the repo is
> > still pretty active in terms of new issues being reported.
> >
> > On 2020-06-03 3:59 p.m., Darryl Pogue wrote:
> > > Correction: There is in fact a deprecation notice, part-way down the
> > > README, but it's not especially attention grabbing and I missed it the
> > > first 2 times I skimmed the file.
> > >
> > > On Wed, Jun 3, 2020 at 11:55 AM Darryl Pogue  wrote:
> > >
> > >> Hey folks,
> > >>
> > >> The File Transfer plugin has been officially deprecated since 2017:
> > >>
> > https://cordova.apache.org/blog/2017/10/18/from-
> filetransfer-to-xhr2.html
> > >>
> > >> However, the repo and npm have no link to that page or any sort of
> > >> indication that it is not maintained.
> > >>
> > >> With the release of cordova-ios 6, the FileTransfer plugin no longer
> > >> compiles on iOS:
> > >> https://github.com/apache/cordova-plugin-file-transfer/issues/258
> > >>
> > >> I want to reply to that issue saying that it's deprecated and not
> > >> maintained, but I feel like we haven't made that very clear.
> > >>
> > >> I would like to propose that we update the README for File Transfer
> > with a
> > >> clear deprecation notice which links to the blog post from 2017, and
> > that
> > >> we ask ASF Infra to mark the repo as archived.
> > >>
> > >> Any objections?
> > >>
> > >> ~Darryl
> > >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>

Re: the future of cordova-plugin-wkwebview-engine

[julio cesar sanchez]

The data lost is not the topic and I don’t think it’s our duty to avoid it
(but we have to document it and mention it on the release notes). For users
concerned about that, there are plugins available (will probably need some
changes because they were created for the ionic plugin).

There are a few more problems with the custom schemes, I don’t remember
them all, but it comes to my head that playing big video files in the video
tag takes a lot of memory and we can’t send the data in chunks because
there are no request headers (I reported it to Apple long ago and it’s not
fixed yet). That doesn’t happen when the video is served from file protocol.

El jueves, 21 de mayo de 2020, Norman Breau 
escribió:

> The only real advantage of using the file protocol is to maintain
> backwards compatibility I think. Other than that, it contains a lot of
> disadvantages, as the webview disables/restricts a lot of browser features
> while on the file protocol, including using XHR to fetch local resources,
> which makes using web frameworks hard to use, such as angular, which
> heavily uses XHR for fetching templates, and is a common source of
> wkwebview related bug reports.
>
> I've just recently migrated an app from UIWebView to the ionic webview,
> which included migrating local storage data that was extremely important
> for us to keep, and that wasn't too difficult to do. It was just simply
> renaming a sqlite database file. So if the primary concern is the protocol
> change causing lost of data (because change of origin), it might be
> possible to write migratory code. I don't know if migrating
> cookies/indexDB/other storage tech is as easy as migrating local storage
> though, I don't use that browser tech, didn't pay attention to it. This
> would obviously delay the cordova-ios@6 release, but would allow us to
> sunset the wkwebview-engine plugin.
>
> On 2020-05-21 1:45 p.m., Michael Gatto wrote:
>
>> Hi,
>>
>> What exactly are the advantages to serving with the file protocol if
>> Cordova doesn't need to?
>>
>> FWIW, I was never able to get WKWebView working without the additional
>> XHR plugin, so serving from file holds no obvious advantage for me, at
>> least.
>>
>> --
>> Michael Gatto
>>
>> ___
>> Michael Gatto · Senior Software Engineer · vinSUITE
>> o: 707-253-7400 e: mga...@vinsuite.com
>> vinsuite <https://www.vinsuite.com/> · twitter  <
>> https://twitter.com/vinsuite>· facebook  <https://www.facebook.com/vinS
>> UITEsoftware/>· linkedin <https://www.linkedin.com/company/vinsuite/>
>>   You sell wine. We make it easier.
>> Top 5 Tasting Room Survey Takeaways - Watch Now! <
>> https://go.vinsuite.com/watch-CellarPass-webinar>
>>
>> On 5/21/20, 9:18 AM, "julio cesar sanchez" 
>> wrote:
>>
>>  we should discuss about what's going to happen
>>  with cordova-plugin-wkwebview-engine
>>   cordova-ios 6 is coming soon and it uses WKWebView, but it uses
>> a custom
>>  scheme to serve the app content instead of serving from file
>> protocol.
>>  some people prefers file over the custom scheme,
>>  but cordova-plugin-wkwebview-engine will not work in cordova-ios 6
>> because
>>  of some breaking changes introduced.
>>   So, should we
>>   a) continue maintaining cordova-plugin-wkwebview-engine and
>> fix it to work
>>  on cordova-ios 6?
>>  b) modify cordova-ios 6 to allow both file and custom scheme and then
>>  sunset cordova-plugin-wkwebview-engine?
>>  c) do nothing and tell people who want to use file protocol to stick
>> with
>>  cordova-ios 5.1.1?
>>  d) other option I didn't think of (please, describe)
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

the future of cordova-plugin-wkwebview-engine

[julio cesar sanchez]

we should discuss about what's going to happen
with cordova-plugin-wkwebview-engine

cordova-ios 6 is coming soon and it uses WKWebView, but it uses a custom
scheme to serve the app content instead of serving from file protocol.
some people prefers file over the custom scheme,
but cordova-plugin-wkwebview-engine will not work in cordova-ios 6 because
of some breaking changes introduced.

So, should we

a) continue maintaining cordova-plugin-wkwebview-engine and fix it to work
on cordova-ios 6?
b) modify cordova-ios 6 to allow both file and custom scheme and then
sunset cordova-plugin-wkwebview-engine?
c) do nothing and tell people who want to use file protocol to stick with
cordova-ios 5.1.1?
d) other option I didn't think of (please, describe)

Re: Request to add to dev mailing list

[julio cesar sanchez]

All the cordova mail lists and instructions about how to subscribe can be
found at
https://cordova.apache.org/contact/

El El mié, 13 may 2020 a las 21:09, Jesse 
escribió:

> Welcome Devendra,
>
> If you would like more info on contributing, there is a ton of info here:
> https://cordova.apache.org/contribute/contribute_guidelines.html
> As well, I believe those on this list would be supportive if you have
> questions, or need help contributing.
>
> That said, please remember that this list is specifically for developing
> Apache Cordova, and is not a community support forum for apps built with
> Cordova.
> The  #slack community is a great place to ask and answer questions as well.
> http://slack.cordova.io/
>
> Cheers,
>   Jesse
>
> On Wed, May 13, 2020 at 12:01 PM Devendra Khatri 
> wrote:
>
> > Hello,
> >
> > I have been working on cordova platform for past 3-4 years, I Keep
> reading
> > blogs about the platform to keep our product stable. I came across this
> > listing recently, If you can add me in the listing !
> >
> > Also, let me know If I need to know any thing else here !!
> >
> > Thanks
> > Devendra
> >
>

Re: [Discuss] Cordova plugin camera release 4.2.0

[julio cesar sanchez]

I've just noticed that
https://github.com/apache/cordova-plugin-camera/pull/588 totally breaks
camera plugin, so we can't release 4.2.0. My bad as I accepted it without
testing on a real device as it looked like a harmless change.


El jue., 7 may. 2020 a las 22:13, Jesse ()
escribió:

> I have closed the vote for Camera-4.2.0
> I will sort out my signing keys and restart tonight.
>
> On Sun, May 3, 2020 at 11:08 PM Jesse  wrote:
>
> > Does anyone have any reason to delay a cordova-plugin-camera release?
> > Any outstanding patches to land?
> >
> > If not, I will start the release soon.
> >
> > (CI is currently green)
> >
>

Re: vote: PR merge convention

[julio cesar sanchez]

It’s not just you Jesse, there are a few in a few repos from different
people. Didn’t mean to attack you, just wanted to remind it as we all agreed

El El sáb, 2 may 2020 a las 20:41, Jesse  escribió:

> I made a mistake, no need to create laws or rules.
>
> > On May 2, 2020, at 11:21 AM, Tim Brust  wrote:
> >
> > +1 to Niklas suggestion :)
> >
> > Sent from my iPhone
> >
> >>> On 2. May 2020, at 6:54 PM, Niklas Merz  wrote:
> >>>
> >>> We could try to enforce this setting with .asf.yml. I saw this posted
> on another list.
> >>>
> >>> See:
> https://cwiki.apache.org/confluence/display/INFRA/.asf.yaml+features+for+git+repositories#id-.asf.yamlfeaturesforgitrepositories-Mergebuttons
> >>>
> >>> Should we roll this out to all repos?
> >>>
> >>> May 2, 2020 1:38 PM, "julio cesar sanchez" 
> wrote:
> >>>
> >>> Just a reminder that we agreed on using the squash and merge, but I
> still
> >>> see regular merge commits in a few repos from time to time.
> >>>
> >>>> El El sáb, 5 oct 2019 a las 19:32, gandhi rajan <
> gandhiraja...@gmail.com>
> >>>> escribió:
> >>>>
> >>>> + 1 for squash and merge as it makes the repo history cleaner.
> >>>>
> >>>>> On Sat, Oct 5, 2019 at 8:34 PM  wrote:
> >>>>
> >>>> +1 for "Squash and merge" as the default strategy
> >>>>
> >>>> Regarding "Create a merge commit":
> >>>> At times, I find this option valuable too. Consider a PR that cleans
> up a
> >>>> test suite. As part of that cleanup I might re-order the test cases.
> As
> >>>> re-ordering produces a noisy diff, I usually isolate it in its own
> >>>> commit.
> >>>> I would not want to merge this commit with the others as that would
> lead
> >>>> to
> >>>> a commit with a very incomprehensible diff. So in this case I would
> favor
> >>>> leaving the commits separate and doing an actual merge to group them
> >>>> together in the global history.
> >>>>
> >>>> Am Fr., 4. Okt. 2019 um 17:03 Uhr schrieb julio cesar sanchez <
> >>>> jcesarmob...@gmail.com>:
> >>>>
> >>>>> Sorry if it wasn't clear, I said I was leaving the protecting master
> >>>> branch
> >>>>> out of the vote.
> >>>>>
> >>>>> Looks like we all agree on using "Squash and merge" as default,
> unless
> >>>> it
> >>>>> makes more sense to use one of the other options.
> >>>>>
> >>>>> El jue., 3 oct. 2019 a las 3:43, Bryan Ellis ()
> >>>>> escribió:
> >>>>>
> >>>>>> -1 for protected master branches.
> >>>>>> Protecting a branch is a great idea except it does not work with our
> >>>>>> current workflow process. COHO commits directly onto the master
> >>>> branch
> >>>>> for
> >>>>>> releases. We would have to spend more time planning and changing our
> >>>>> entire
> >>>>>> current workflow process to eliminate direct commits if we wanted to
> >>>>>> protect branches. There is alternative such keeping master open for
> >>>>> direct
> >>>>>> commits and development while creating a protected "production"
> >>>> branch.
> >>>>>> Anyways this part of the discussion is off-topic and could be
> another
> >>>>>> discussion... Anyways, stated above I am downvoting protected
> >>>> branches
> >>>>> for
> >>>>>> now.
> >>>>>>
> >>>>>> +1 for "Squash and merge"
> >>>>>> Makes a nice single commit with the PR number and without the extra
> >>>> merge
> >>>>>> commit.
> >>>>>>
> >>>>>> +1 for "Rebase and merge"
> >>>>>> There are use cases where this can work perfectly.
> >>>>>> For example, Cordova-Electron has a `draft-2.0.0` branch which is
> >>>>> targeting
> >>>>>> the next major release. Major PRs were merged into that branch with
> >>>>> "Squash
> >>>>>>

Re: vote: PR merge convention

[julio cesar sanchez]

Just a reminder that we agreed on using the squash and merge, but I still
see regular merge commits in a few repos from time to time.

El El sáb, 5 oct 2019 a las 19:32, gandhi rajan 
escribió:

> + 1 for squash and merge as it makes the repo history cleaner.
>
> On Sat, Oct 5, 2019 at 8:34 PM  wrote:
>
> > +1 for "Squash and merge" as the default strategy
> >
> > Regarding "Create a merge commit":
> > At times, I find this option valuable too. Consider a PR that cleans up a
> > test suite. As part of that cleanup I might re-order the test cases. As
> > re-ordering produces a noisy diff, I usually isolate it in its own
> commit.
> > I would not want to merge this commit with the others as that would lead
> to
> > a commit with a very incomprehensible diff. So in this case I would favor
> > leaving the commits separate and doing an actual merge to group them
> > together in the global history.
> >
> > Am Fr., 4. Okt. 2019 um 17:03 Uhr schrieb julio cesar sanchez <
> > jcesarmob...@gmail.com>:
> >
> > > Sorry if it wasn't clear, I said I was leaving the protecting master
> > branch
> > > out of the vote.
> > >
> > > Looks like we all agree on using "Squash and merge" as default, unless
> it
> > > makes more sense to use one of the other options.
> > >
> > > El jue., 3 oct. 2019 a las 3:43, Bryan Ellis ()
> > > escribió:
> > >
> > > > -1 for protected master branches.
> > > > Protecting a branch is a great idea except it does not work with our
> > > > current workflow process. COHO commits directly onto the master
> branch
> > > for
> > > > releases. We would have to spend more time planning and changing our
> > > entire
> > > > current workflow process to eliminate direct commits if we wanted to
> > > > protect branches. There is alternative such keeping master open for
> > > direct
> > > > commits and development while creating a protected "production"
> branch.
> > > > Anyways this part of the discussion is off-topic and could be another
> > > > discussion... Anyways, stated above I am downvoting protected
> branches
> > > for
> > > > now.
> > > >
> > > > +1 for "Squash and merge"
> > > > Makes a nice single commit with the PR number and without the extra
> > merge
> > > > commit.
> > > >
> > > > +1 for "Rebase and merge"
> > > > There are use cases where this can work perfectly.
> > > > For example, Cordova-Electron has a `draft-2.0.0` branch which is
> > > targeting
> > > > the next major release. Major PRs were merged into that branch with
> > > "Squash
> > > > and merge". This means all PRs have nice PR# information in the
> title.
> > > > A PR will later be created to merge this branch onto master. "Rebase
> > and
> > > > merge" will be used and will not create the merge commit message and
> > will
> > > > not squash.
> > > >
> > > > -1 for "Create a merge commit"
> > > > Not in favor of the extra merge commit. I think in most cases one PR
> > > should
> > > > focus on one task so that means it could be squashed when there are
> > > > multiple commits. If "Create a merge commit" is used, each commit
> will
> > be
> > > > merged and does not contain the PR# in the title. When creating
> release
> > > > notes, I need to manually review those commits to identify what PR it
> > > came
> > > > from to include the PR linking. Some times, depending on if they are
> > all
> > > > related commits, I need to manually group them and create a
> meaningful
> > > > title for the release notes which I would prefer to have been done
> > > > beforehand.
> > > >
> > > >
> > > > On Wed, Oct 2, 2019 at 12:51 AM Jesse 
> wrote:
> > > >
> > > > > -1 for protected master branches, we are a small group of
> committers
> > > and
> > > > > don't need rules to keep us honest.
> > > > > Protecting master would involve infra, as we cannot manage the
> > minutia
> > > in
> > > > > github.  I think we all do this anyway except for rare occasions.
> > > > >
> > > > > +1 for squash and merge, as long as the meaningful individual
> commit
> > >

Re: [PROPOSAL] Enable Probot Apps to Improve Issue Tracker

[julio cesar sanchez]

I'm -1 for the stale bot, I've seen in other repos and it just ends closing
valid issues and PRs because the maintainers didn't have time to look into
them, but that's maintainers "fault" and I think it "punish" users.

I'm +1 for the other ones.

El vie., 17 abr. 2020 a las 12:43, Bryan Ellis ()
escribió:

> I forgot to link PR:
>
> https://github.com/apache/cordova/pull/210
>
> This PR contains the configurations for the apps described previously.
>
>
> On Fri, Apr 17, 2020 at 7:42 PM Bryan Ellis  wrote:
>
> > I would like to better improve our GitHub issue tracker by adding some of
> > the Probot apps that can be installed to GitHub.
> >
> >
> > There are many available apps and I wanted to start off with a selected
> > few that would help mitigate some of the tedious tasks.
> >
> > The apps I would like to bring up in this discussion and to vote on are:
> >
> >- Stale
> >- Request Info
> >- Lock Threads
> >- No Response
> >
> >
> > The "*Stale*" app is used to automatically close issues and prs which
> > have no activity over a period of time. This app provides a lot of
> > configuration flexibility. We can warn users after x number of days that
> > the issue/pr has become stale and append a stale label. After x number of
> > days being stale, then the app will close the issue/pr. We can ensure
> that
> > the issues and prs are not closed immediately and provide users ample
> time
> > to reply back.
> >
> >
> > The "*Request Info*" app is used to automatically alert users when they
> > have created a new issue or pr that does not have any description. The
> app
> > will inform them that they will need to provide information for use to be
> > able to help them. One of the great things about this app is that it can
> > also check against our templates. If a user has submitted an issue or pr
> > with only the default template, it will also fail the check.
> >
> >
> > The "*No Response*" app is used to automatically close issues that have
> > not received a response from the author. This app pairs nicely with the
> > "request-info" app which manages the warning and label pinning. This app,
> > on the other hand, does not support PRs as the "request-info" also
> > supports. This means we will need to manually manage PRs in the meantime
> > while we wait for the app to be updated.
> >
> >
> > The "*Lock Threads*" app is used to lock the threads of closed issues or
> > prs after (x) number of days of inactivity. This is to help prevent
> > long-lived issues and prs after being resolved and closed. If a user
> still
> > has issues to report after the thread of an issue or PR is locked, they
> > should create a new issue. The locking of the thread does not occur
> > immediately after an issue or PR is closed. Users can still have an
> > opportunity to communicate if they feel the issue was closed prematurely.
> >
> >
> > Here is an example of PR to configure and use the bots. Obviously, I
> would
> > also need to enable the bot on each repo.
> >
> >
> > Please let me know what is your thoughts on this and even make a vote on
> > it. I would like to move forward and start using the power of the apps
> that
> > can be installed.
> >
> >
> > Here is the general process based on the configurations in the PR.
> >
> >
> > *For proper Issues & PRs*
> >
> >- After 2 months of no activity, the issue/pr will become stale and
> >the thread will be warned. A "stale" label is appended.
> >- After 2 weeks of being stale, and continues to have no activity, the
> >issue/pr is closed.
> >- After 2 weeks of being closed, and continues to have no activity,
> >the issue/pr thread will become locked.
> >
> >
> > In total, this process covers ~3 months. (88 days exactly). After being
> > flagged stale, users have still enough time to create an activity to
> > prevent the app from closing and locking the thread.
> >
> >
> > Additionally, I have also declared labels of "security" and "pinned" to
> be
> > ignored by the app so it will never go stale.
> >
> >
> > *For issues & PRs that have no description or matches the template.*
> >
> >- Shortly after the submission of a bad issue or pr, the app will post
> >a warning that information must be provided. Also, "info-needed"
> label is
> >applied
> >- After 4 days of no response, the bot will close the issue. (PR will
> >need to be manually managed for now)
> >- After 2 weeks of being closed, and continues to have no activity,
> >the issue/pr thread will become locked.
> >
> >
> > In total, this process covers ~18 days. The author of the ticket will
> have
> > enough time to correct the issue before the app closes and locks the
> thread.
> >
> >
> > If we have enough votes for this, what I will do is merge in the PR and
> > then do a mass deploy to all repos. I will also enable the bots to each
> > repo.
> >
> > Please provide a vote on this as well.
> >
> >
> >
>

Re: Frustration with Cordova documentation

[julio cesar sanchez]

Maybe we should add the error code on the blog entry (*ITMS-90809*), that
way people can end up on the blog when searching about. Right now first
entry is the ionic blog, I checked 5 pages and didn’t find anything cordova
specific.

El miércoles, 1 de abril de 2020, Niklas Merz 
escribió:

> I think there is good documentation for this particular problem. I wrote a
> blog post {1} just two weeks ago to summarize it now that Apple is
> enforcing it. Most people just don't research properly and just ask and we
> can't do anything about it.
>
> But yes we really should get this money for better docs used now. I just
> don't know how to get this going. I guess we need to find a technical
> writer/developer capable of doing it.
>
> {1} https://cordova.apache.org/howto/2020/03/18/wkwebviewonly.html
>
> April 1, 2020 2:58 AM, "Chris Brody"  wrote:
>
> > Improvement has already been sponsored by an anonymous donor. Repeated
> > requests for help with getting it started have been met with no response
> so
> > far. I think this recent thread is an example of how our documentation
> > could use some improvement:
> >
> > https://lists.apache.org/thread.html/r261aa09ef8e4b0d47ceda731d38a5
> 8204186d544528b07c27898c000@ > ordova.apache.org>
> >
> > I sincerely hope I am just missing something here, would love to get the
> > ball rolling in the near future.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: UiwebView deprecated issue for my App

[julio cesar sanchez]

There is also an entry about it on the Apache cordova blog

https://cordova.apache.org/howto/2020/03/18/wkwebviewonly.html

But as Chris said, doesn’t look like you did any research, if you google “
*ITMS-90809”* (the error you get when you submit the app),  the first
result is the ionic blog post he linked.


El miércoles, 1 de abril de 2020, Chris Brody 
escribió:

> The answer is already documented. We would really appreciate it if users
> could a little more research since maintainers are generally overloaded,
> especially while they are busy with a new major release.
>
> That said, here is a recommended link that I found from a quick search:
> https://ionicframework.com/blog/understanding-itms-90809-
> uiwebview-api-deprecation/
>
> I do think our documentation could use some improvement, and it has already
> been sponsored by an anonymous donor:
> https://github.com/apache/cordova-docs/issues/1057
>
>
> On Tue, Mar 31, 2020 at 8:48 PM Jesse  wrote:
>
> > Hi Binay,
> >
> > This list is for development of Apache Cordova itself.  For issues using
> > Apache Cordova in your app, your best bet is either via our slack channel
> > [1]
> > or stack overflow [2]
> > That said, it sounds like Ionic support might be a better option for your
> > issue.
> >
> > Cheers,
> >   Jesse
> >
> >
> > [1] https://slack-cordova-io.herokuapp.com/
> > [2] https://stackoverflow.com/questions/tagged/cordova
> >
> > On Tue, Mar 31, 2020 at 5:40 PM Binay Prabhakar 
> > wrote:
> >
> > > Hi Corodova Team,
> > > Six month back when I started working on Ionic App I was Very excited
> > > about it.
> > > But things are not smooth since few weeks.
> > > When I uploaded my app to test flight there were UI Web View
> depreciated
> > > warning came to me.
> > > To solve it i have migrated the app to Ionic 5 with a hope that this
> > issue
> > > will be solved.
> > > But sad part is that still Apple gave the same warning of Ui
> > depreciation.
> > > Can you please help me on this!
> > > Tried everything..Even created sample ionic project in ionic 5 and
> tried
> > > to build it but in ios code what I can see is there are references of
> > > UiwebView.
> > > Any proper blog will be helpful if you can suggest.
> > >
> > >
> > > Get Outlook for Android
> > >
> >
>

Re: Statusbar Plugin Release?

[julio cesar sanchez]

I already mentioned it

"The plugin would need a major release because we removed the deprecated
platforms."

I think removing platforms, despite they are deprecated, is a breaking
change. At least in other plugins we did a major release after that.

El vie., 20 mar. 2020 a las 19:22, Chris Brody ()
escribió:

> Can you remind forgetful people like me what would trigger a major release
> here?
>
> It would be ideal to make a minor with bug fixes first but I suspect this
> would not be worth anyone’s time.
>
> On Fri, Mar 20, 2020 at 2:08 PM Niklas Merz  wrote:
>
> > Good. I will have a look in the next few days. Triage PRs and try to
> > prepare a major.
> >
> > Am 20. März 2020, 17:01, um 17:01, Chris Brody 
> > schrieb:
> > >+1 for making the release if we can get some of the more important PRs
> > >merged soon.
> > >
> > >We do have discussions of deprecating plugins but I think they are not
> > >really solid plans yet.
> > >
> > >
> > >On Fri, Mar 20, 2020 at 11:42 AM julio cesar sanchez
> > >
> > >wrote:
> > >
> > >> The idea was to integrate it into the platforms, but we can probably
> > >leave
> > >> that out for next major releases (next year releases).
> > >> The plugin would need a major release because we removed the
> > >deprecated
> > >> platforms.
> > >>
> > >> There are a few pending PRs that should be merged before doing the
> > >release.
> > >>
> > >> El vie., 20 mar. 2020 a las 16:31, Niklas Merz
> > >()
> > >> escribió:
> > >>
> > >> > Hello everyone,
> > >> >
> > >> > Currently I am struggeling with a statusbar issue. There is a fix
> > >in
> > >> > master [1] and now I am wondering if we plan to do a release for
> > >this
> > >> > plugin.
> > >> >
> > >> > I am not sure but are there any plans to deprecate this plugin or
> > >> > something? There is something in my head but I can't remember
> > >exactly.
> > >> > Sorry for asking.
> > >> >
> > >> > Thanks and kind regards
> > >> > Niklas
> > >> >
> > >> > [1]
> > >> >
> > >>
> > >
> >
> https://github.com/apache/cordova-plugin-statusbar/commit/7d5d067f0391a9b07fae2ea89de818d0f2247527
> > >> >
> > >> >
> > >-
> > >> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > >> > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >> >
> > >> >
> > >>
> >
> --
> Sent from my mobile
>

Re: Statusbar Plugin Release?

[julio cesar sanchez]

The idea was to integrate it into the platforms, but we can probably leave
that out for next major releases (next year releases).
The plugin would need a major release because we removed the deprecated
platforms.

There are a few pending PRs that should be merged before doing the release.

El vie., 20 mar. 2020 a las 16:31, Niklas Merz ()
escribió:

> Hello everyone,
>
> Currently I am struggeling with a statusbar issue. There is a fix in
> master [1] and now I am wondering if we plan to do a release for this
> plugin.
>
> I am not sure but are there any plans to deprecate this plugin or
> something? There is something in my head but I can't remember exactly.
> Sorry for asking.
>
> Thanks and kind regards
> Niklas
>
> [1]
> https://github.com/apache/cordova-plugin-statusbar/commit/7d5d067f0391a9b07fae2ea89de818d0f2247527
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Looking for guidance to contribute Cordova

[julio cesar sanchez]

Hello,

Welcome to the cordova dev list.

I don’t think any Cordova PMC applied to GSOC to be a mentor, so if Apache
appears as organization is probably from other projects. Not sure if people
from other projects can be mentors for Cordova.

But you don’t need to be on GSOC to contribute to Cordova, you can just
start contributing by sending pull request to any of the Cordova
repositories (https://github.com/apache?utf8=✓=cordova-)
You can check the contribution guidelines here
https://cordova.apache.org/contribute/contribute_guidelines.html

Even if you don’t have a dedicated mentor, you can ask any question here on
the dev list and we will try to help you.


El sábado, 15 de febrero de 2020, Bhathiya Mihiran 
escribió:

> Hello,
> I'm Bhathiya Mihiran, a final year undergraduate student pursuing BSc in
> Information Systems from University of Colombo School of Computing who
> interested to do GSOC.  I have some experience in mobile app development
> and web application development
> I went through some projects of apache and I found interested in Apache
> Cordova as it related to my technical stack. Therefore I decided to
> contribute to the Cordova.
> So I would like to request for guidance to contribute for the Cordova.
> Thank you!!
>

Re: [PROPOSAL] Update Cordova iOS Platform Xcode Compatibility

[julio cesar sanchez]

+1

note that maybe it's not clear, but we would remove Xcode 10 support as
using the Xcode 11 structure will make apps incompatible with previous
Xcode versions.

Dropping Xcode 10 support can also simplify some plugins code that have
additional code macros to work on Xcode 10 at the moment.


El lun., 10 feb. 2020 a las 14:54, Bryan Ellis ()
escribió:

> I accidentally clicked on the send button before adding the PR link that I
> already submitted.
>
> https://github.com/apache/cordova-ios/pull/780
>
> I also *+1* for setting the "*Project Format*" to "*Xcode 11-compatible*"
>
>
> On Mon, Feb 10, 2020 at 10:51 PM Bryan Ellis  wrote:
>
> > I would like to open the discussion and vote to *update the Cordova iOS
> > Xcode "Project Format" setting to Xcode 11-compatible* for the upcoming
> > next major release.
> >
> > I have already created a PR that performs the changes but would like to
> > get feedback from others regarding this change in general and maybe a
> > review.
> >
> > One of the major reasons for this change is to conform with the *App
> > Store Submission[1]* guidelines:
> >
> > Starting April, 2020, all apps submitted to the App Store will need to be
> > built with Xcode 11. Xcode 11 requires macOS Mojave 10.14.3 or later.
> >
> >
> > Additionally,
> >
> > This change would modernize our default project template, CordovaLib, and
> > as well as the testing fixtures.
> >
> > And also, quoted from Apple's *WWDC 2019 Video[2]*
> >
> > Keeping your project file modern is a critical way to make sure that
> Xcode
> > can help you out and avoids the accumulation of issues.
> > First, when you're updating to a new version of Xcode, you'll be offered
> > the opportunity sometimes to have Xcode update the project settings and
> > update your project file to the latest format.
> >
> >
> > *Reference Links*
> > *App Store Submission*
> > [1] https://developer.apple.com/app-store/submissions/
> >
> > *WWDC 2019 Video*
> > [2] https://developer.apple.com/videos/play/wwdc2019/239/
> >
>

Re: [PROPOSAL] Drop Android 4.4 Support

[julio cesar sanchez]

I like the "we officially support SDK 22, SDK 21 might work", I'm +1 on SDK
22 then

But for ES6, I think that's a bigger problem.
Android 5+ is supposed to have the updatable webview, but that's not always
true, some vendors didn't implement it for some reason.
Also, even if implemented, users might not have the webview up to date.
And devs testing if their apps work on Android 5-6 will probably test on
emulators, which don't support ES6 and their webview can't be updated.

And worst of all, there are no stats about that, so we can't know for sure
how many users will be affected by this.



El mar., 28 ene. 2020 a las 17:14, Bryan Ellis ()
escribió:

> My primary view for dropping 5.0 was also based off of low usage.
>
> Obviously there will always be vulnerabilities. The CVE list showed a
> dropped from 5.0.0 to 5.0.2 but an increase again in 5.1. This, of course,
> will always be expected on minor and major releases.
>
> It was also known that 5.0 has a severe memory leak that users were
> experiencing and resolved in 5.1.
>
> We would set the minSdk higher but that does not mean users cant lower it
> to support 5.0, at their own risk. This value could be set in config.xml.
>
> What we would say could be along the lines of, it might work with 5.0 but
> we officially support is 5.1.
>
> Lastly, if we started to convert the browser code to ES6, for example, it
> will not work on Android 4.4. These are changes that would possibly come.
> We just have to think about the "updatable webview" when that time comes.
>
>
> On Wed, Jan 29, 2020 at 12:53 AM Chris Brody 
> wrote:
>
> > +1 to drop Android 4.4 support
> >
> > > Do we have a reason for 5.1 instead of 5.0 other than the low usage?
> > >
> > > Originally, I was thinking 5.0+, but after seeing low usage, I leaned
> > > over to 5.1. So low usage was my primary reasoning for my +1.
> >
> > +1 to drop 5.0 and +1 on the reasoning here
> >
> > I don't recall seeing a device running 5.0 for quite a few years. I
> > recall seeing "Android 5" or "Android 5.0" devices actually running
> > 5.1 or 5.1.1. (Unfortunately my memory is a bit hazy on this.)
> >
> > A side question is the how. Would we just set a higher
> > minimumSdkVersion number (if I spelled it right) or do something else?
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>

Re: [PROPOSAL] Drop Android 4.4 Support

[julio cesar sanchez]

+1 for dropping Android 4.4 since it doesn't have updatable webview and
it's a pain to maintain such old chromium version

Do we have a reason for 5.1 instead of 5.0 other than the low usage?



El mar., 28 ene. 2020 a las 16:13, Norman Breau ()
escribió:

> +1 to drop Android 4.4 - 5.0.
> +1 to support Android >= 5.1
>
> On 2020-01-28 10:59 a.m., Bryan Ellis wrote:
> > I would like to open the discussion and vote to *drop Android 4.4
> (KitKat)
> > support* in the upcoming next major release.
> >
> > As of Dec 2019, Stat Counter reports that the *market share for Android
> 4.4
> > is only at 2.6%*.
> >
> > Additionally, there is a report of *128 vulnerabilities in Android
> 4.4.4*.
> > As far as security updates for KitKat, there are none. The last release
> of
> > KitKat was 5 years and 2 months ago.
> >
> > I think it is safe to say that deprecating Android 4.4 support is a good
> > move.
> >
> > Lastly, IF the votes are more in favor of dropping, the next question
> would
> > be what version should be supported at minimum.
> >
> > Looking back at the Stat Counter[1] , it shows:
> > * Android 5.0 (Lollipop) has 1.46% market share
> > * Android 5.1 (Lollipop) has 6.04% market share
> >
> > Looking at the percentage, maybe we could decide on starting from version
> > 5.1 at a minimum. (Android 5.0 + Android 4.4 = 4.06% that will not be
> > supported)
> >
> > To sum up the proposal, I want to vote on:
> > * Drop Android 4.4
> > * Support Android 5.1 at minimum (Android >= 5.1 = 95.94% coverage)
> >
> >
> > *Reference Links*
> > *Stat Counter*
> > [1]
> >
> https://gs.statcounter.com/android-version-market-share/mobile-tablet/worldwide
> > *Common Vulnerabilities and Exposures Details*
> > [2]
> >
> https://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-19997/version_id-177951/Google-Android-4.4.4.html
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Automatic Cordova cleanup command

[julio cesar sanchez]

There is a cordova clean command, not sure if it does what you want, I've
never used it.

El mié., 22 ene. 2020 a las 9:20, Tim Brust
() escribió:

> Isn't rm -r platform plugins enough?
>
> On Wed, Jan 22, 2020 at 2:00 AM Chris Brody  wrote:
>
> > We can see from issues like
> > https://github.com/xpbrew/cordova-sqlite-storage/issues/856 that
> extremely
> > weird behavior can happen when projects become outdated.
> >
> > I think there should be a CLI command that cleans up the project
> workarea:
> > purge out old plugins and platforms and ensure that all configuration is
> > properly migrated.
> >
>
>
> --
> Tim Brust, Product Engineer
>
> tim.br...@sinnerschrader.com
> T +49 40 398855 315
>
> SinnerSchrader Deutschland GmbH | SinnerSchrader Group
> Völckersstraße 38, 22765 Hamburg, Germany
>
> Amtsgericht Hamburg HRB-Nr. 63663
> Geschäftsführer: Matthias Schrader (Sprecher),
> Jürgen Alker, Dr. Axel Averdung, Holger Blank,
> Thomas Dyckhoff, Dr. Lars Finke, Martin Gassner, Peggy Hutchinson
>
> Büros: Berlin, Hamburg, Frankfurt a. M., München, Prag
>
> https://www.sinnerschrader.com | NEXT AGENCY
>

Re: Questions about cordova-coho

[julio cesar sanchez]

I have GitHub set to use 2FA but I always use https, you just need to add a
token or something (I just did it a few weeks ago and already forgot how I
did it)

El El mié, 1 ene 2020 a las 19:01, Niklas Merz 
escribió:

> Oops forgott to past the links
>
> [1] https://github.com/apache/cordova-contribute
>
> [2] https://github.com/apache/cordova-coho/tree/master/docs
>
> [3]
>
> https://github.com/apache/cordova-coho/blob/master/docs/committer-workflow.md
>
>
> Thanks Chris. Your workflow sounds good. I think I will figure out what
> works best for me. I created a PR to change coho to SSH [4], but maybe
> having origin read-only this way, is a really good idea to avoid
> accidental pushes.
>
> [4] https://github.com/apache/cordova-coho/pull/264
>
> Am 01.01.20 um 18:52 schrieb Chris Brody:
> > I generally clone with the https address and then add a second git remote
> > with the ssh URL that I can push to.
> >
> > I use this technique to hopefully reduce the chance of doing git push
> with
> > something wrong.
> >
> > One trick I discovered is that you can use the https address from the
> > address bar when cloning from GitHub.
> >
> > I did not see anything for your references [1], [2], or [3].
> >
> > Happy new year!
> >
> >
> > On Wed, Jan 1, 2020 at 12:45 PM Niklas Merz 
> wrote:
> >
> >> Happy New Year everyone,
> >>
> >> I am still going through documents and repos to find more about the
> >> development processes and tools in Cordova. I found those two seemingly
> >> most relevant repos [1] and [2].
> >>
> >> While going through this doc and setting up [3], I wondered why
> >> cordova-coho just uses HTTPS for the repos? I am using SSH for all git
> >> repos because of 2FA and ease of use.
> >>
> >> So that are questions. Is anyone/everyone using cordova-coho? If so, are
> >> you using it via HTTPS? I changed it for me to SSH. Does it make sense
> >> to make PR which adds this? If yes, should I make it via a CLI flag or
> >> as default.
> >>
> >> Looking forward, to your feedback. I am still finding my way how work
> >> efficiently with development on Cordova.
> >>
> >> Regards Niklas
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >> For additional commands, e-mail: dev-h...@cordova.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [DISCUSS] cordova-windows 2.0.1 patch release

[julio cesar sanchez]

7.0.1, not 2.0.1

El El dom, 29 dic 2019 a las 19:46, Chris Brody 
escribió:

> Does anyone have any reason to delay a cordova-windows 2.0.1 patch release?
>
> Any outstanding patches to land?
>
> If not, I will start the release tomorrow.
>
> Purpose is to resolve an issue with WinJS which seems to affect many users
> including myself. I have cherry-picked a very limited number of changes as
> discussed here: https://github.com/apache/cordova-windows/pull/372
>

Re: cordova-android and java requirement

[julio cesar sanchez]

Looks like gradlew commands try to run java internally, so I think we are
good requiring Java 8.

El lun., 9 dic. 2019 a las 18:21, julio cesar sanchez (<
jcesarmob...@gmail.com>) escribió:

> Just checked the docs and in the Android requirements we tell to install
> Android Studio to install the Android SDK
>
> Android SDK
>> Install Android Studio. Follow the instructions at the linked Android
>> Developer site to get started. Opening Android Studio for the first time
>> will guide you through the process of installing the Android SDK.
>
>
> El lun., 9 dic. 2019 a las 17:04, Norman Breau ()
> escribió:
>
>> Installing JDK yourself will probably be required if you just install
>> the android SDK without installing android studio, so I don't think we
>> should necessary **depend** on android studio, but I think Cordova could
>> be smarter to look for a java install inside android studio.
>>
>> On 2019-12-09 12:01 p.m., Norman Breau wrote:
>> > Not 100% if it is still required but this is probably a legacy
>> > requirement. Android Studio started including the JDK in AS 2.2, which
>> > was released in 2016.
>> >
>> > I just checked my android studio install for linux, and I have a java
>> > install location at /jre/ and it is version 1.8.0_152
>> >
>> > On 2019-12-09 10:43 a.m., julio cesar sanchez wrote:
>> >> Do anybody know why we still require java for cordova-android?
>> >>
>> >> Just did a clean install on my computer and after installing cordova
>> and
>> >> trying to run it's complaining about java not installed. We not just
>> >> require Java, we require Java 8, while latest is 13.
>> >> I know Java 8 is required for Android development, but the thing is,
>> >> Android Studio includes a JDK 8 you can use to run apps. I can run
>> >> native
>> >> apps without any problem without java installed. Not just that, I can
>> >> run
>> >> Cordova apps if I open the Android project at /platforms/android.
>> >>
>> >> So, does it still make sense to keep that requirement and force users
>> to
>> >> have Java 8 installed in their systems?
>> >> Is it required by the CLI or some command we use to run the app?
>> >>
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> > For additional commands, e-mail: dev-h...@cordova.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>

Re: cordova-android and java requirement

[julio cesar sanchez]

Just checked the docs and in the Android requirements we tell to install
Android Studio to install the Android SDK

Android SDK
> Install Android Studio. Follow the instructions at the linked Android
> Developer site to get started. Opening Android Studio for the first time
> will guide you through the process of installing the Android SDK.


El lun., 9 dic. 2019 a las 17:04, Norman Breau ()
escribió:

> Installing JDK yourself will probably be required if you just install
> the android SDK without installing android studio, so I don't think we
> should necessary **depend** on android studio, but I think Cordova could
> be smarter to look for a java install inside android studio.
>
> On 2019-12-09 12:01 p.m., Norman Breau wrote:
> > Not 100% if it is still required but this is probably a legacy
> > requirement. Android Studio started including the JDK in AS 2.2, which
> > was released in 2016.
> >
> > I just checked my android studio install for linux, and I have a java
> > install location at /jre/ and it is version 1.8.0_152
> >
> > On 2019-12-09 10:43 a.m., julio cesar sanchez wrote:
> >> Do anybody know why we still require java for cordova-android?
> >>
> >> Just did a clean install on my computer and after installing cordova and
> >> trying to run it's complaining about java not installed. We not just
> >> require Java, we require Java 8, while latest is 13.
> >> I know Java 8 is required for Android development, but the thing is,
> >> Android Studio includes a JDK 8 you can use to run apps. I can run
> >> native
> >> apps without any problem without java installed. Not just that, I can
> >> run
> >> Cordova apps if I open the Android project at /platforms/android.
> >>
> >> So, does it still make sense to keep that requirement and force users to
> >> have Java 8 installed in their systems?
> >> Is it required by the CLI or some command we use to run the app?
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

cordova-android and java requirement

[julio cesar sanchez]

Do anybody know why we still require java for cordova-android?

Just did a clean install on my computer and after installing cordova and
trying to run it's complaining about java not installed. We not just
require Java, we require Java 8, while latest is 13.
I know Java 8 is required for Android development, but the thing is,
Android Studio includes a JDK 8 you can use to run apps. I can run native
apps without any problem without java installed. Not just that, I can run
Cordova apps if I open the Android project at /platforms/android.

So, does it still make sense to keep that requirement and force users to
have Java 8 installed in their systems?
Is it required by the CLI or some command we use to run the app?

Re: [DISCUSS] Cordova-iOS 5.1.1 Patch Release

[julio cesar sanchez]

That should be a separate discussion.
But basically that preference is for people not using UIWebView, if they or
their plugins are using it it won’t work, that’s expected.
In plugins I would rather remove the whole UIWebView code than adding the
conditional compile option, I already sent a pr that removes it long ago.
But I think we should do a release first before merging that breaking
change, since at the moment, latest released version of InAppBrowser
doesn’t work on iOS 13 if using WKWebView option and has been fixed for a
few weeks in master. (There is already a thread proposing the release)

El domingo, 1 de diciembre de 2019, Tim Brust
 escribió:

> I'd like to bring attention to the fact, that even with the 5.1.1 release
> the cordova-plugin-inappbrowser will need an update, too.
> It's already reported that it's not working with cordova-ios 5.1.0 and the
> WKWebViewOnly flag enabled.
> Issue: https://github.com/apache/cordova-plugin-inappbrowser/issues/583,
> potential PR:
> https://github.com/apache/cordova-plugin-inappbrowser/issues/584
>
> On Thu, Nov 28, 2019 at 1:47 PM Bryan Ellis  wrote:
>
> > Correction:
> >
> > The current changes link is written correctly but hyperlink is incorrect.
> > Here is the correct link.
> >
> > https://github.com/apache/cordova-ios/compare/rel/5.1.0...master
> >
> > Please also note that the 5.2.0-dev related commits will not be
> > cherry-picked into the 5.1.x branch or in the 5.1.1 release.
> >
> > On Thu, Nov 28, 2019 at 10:05 PM Bryan Ellis  wrote:
> >
> > > Does anyone have any reason to delay a cordova-ios patch release
> (5.1.1)?
> > >
> > > Any outstanding patches to land?
> > >
> > > Current changes:
> > > https://github.com/apache/cordova-ios/compare/rel/5.1.0...master
> > > 
> > >
> > > As a bug was introduced in the minor release, I will go ahead and
> submit
> > > the vote shortly to get a quick turnaround on the patch release.
> > >
> >
>
>
> --
> Tim Brust, Product Engineer
>
> tim.br...@sinnerschrader.com
> T +49 40 398855 315
>
> SinnerSchrader Deutschland GmbH | SinnerSchrader Group
> Völckersstraße 38, 22765 Hamburg, Germany
>
> Amtsgericht Hamburg HRB-Nr. 63663
> Geschäftsführer: Matthias Schrader (Sprecher),
> Jürgen Alker, Dr. Axel Averdung, Holger Blank,
> Thomas Dyckhoff, Dr. Lars Finke, Martin Gassner, Peggy Hutchinson
>
> Büros: Berlin, Hamburg, Frankfurt a. M., München, Prag
>
> https://www.sinnerschrader.com | NEXT AGENCY
>

Re: [VOTE] Cordova-iOS 5.1.1 Release

[julio cesar sanchez]

I vote +1

ran npm test
ran npm audit
created an app with the new preference and ran it without problems

El sáb., 30 nov. 2019 a las 17:47, Jesse ()
escribió:

> +1
>
> - ci is green
> - coho verify-archive
> - ran tests locally, npm audit
>
> On Thu, Nov 28, 2019 at 11:46 PM Niklas Merz 
> wrote:
>
> > I vote +1 (non-binding)
> > * CI is greeen for tag
> > * Confirmed sigs & hashes with `coho verify-archive` [1]
> > * Verified sha1s match tags with `coho@nightly verify-tags`
> > * Created a new cordova project, added the platform and launched
> > successfully on iPhone
> >
> > - Ursprüngliche Nachricht -
> > Von: "Bryan Ellis" 
> > An: dev@cordova.apache.org
> > CC:
> > Betreff: [VOTE] Cordova-iOS 5.1.1 Release
> > Datum: Do, 28. Nov 2019 18:25
> >
> > Please review and vote on this iOS Release v5.1.1
> > by replying to this email (and keep discussion on the DISCUSS thread)
> >
> > The archive has been published to dist/dev:
> > https://dist.apache.org/repos/dist/dev/cordova/ios-v5.1.1
> >
> > The package was published from its corresponding git tag:
> > cordova-ios: 5.1.1 (86a87fed74)
> >
> > Note that you can test it out via:
> >
> > cordova platform add https://github.com/apache/cordova-ios#5.1.1
> >
> > Upon a successful vote I will upload the archive to dist/, publish it to
> > npm, and post the blog post.
> >
> > 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
> > * Ensured continuous build was green when repo was tagged
> > * NPM Audit
> > * NPM Tests
> > * Build Tests
> >
> >
> > Sitz der Gesellschaft: GEDYS IntraWare GmbH, Brückenmühle 93, 36100
> > Petersberg, Deutschland
> > Tel.: +49 661 9642-0 | Fax: +49 661 9642-99 | i...@gedys-intraware.de |
> > www.gedys-intraware.de
> > Registereintragung: Amtsgericht Fulda HRB 5156 | Ust.-ID: DE 188 682 194
> > gemäß Paragraph 27a UstG  | Geschäftsführung: Joachim Weber, Ralf
> > Geishauser, Frank Hohl
> > AGB | Impressum | Datenschutzbestimmungen
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>

Re: Preparing Platforms for Next Major

[julio cesar sanchez]

For iOS we have been talking about releasing the conditional compile time
UIWebView removal in a minor release.
https://github.com/apache/cordova-discuss/pull/110
But was not decided and current PR doesn’t apply changes to already added
platforms, so it needs to remove and add again, which is not ideal.
That link also contains a few things we should do for the next cordova-ios
major release

El martes, 5 de noviembre de 2019, Bryan Ellis  escribió:

> Does anyone have any reason to delay moving forward with releasing the next
> major (breaking changes) PRs to our platform repos?
>
> Most of the tooling repos have already moved forward and merged in the next
> major PRs.
>
> Platforms are beginning to get next-major PRs and we would like to start
> reviewing and merging them. As well we would like to continue submitting
> more of these major changes that might also rely on other PRs.
>
> If anyone has work that they feel or would like to see released beforehand,
> it might be a good time to start planning and preparing a patch or minor
> release.
>

Re: [DISCUSS] Deprecation of allowing remote urls in config's

[julio cesar sanchez]

I have not tested, but supposedly you can point to a local html error file.
Whenever a navigation error occurs, it should navigate to that local page.




Anyway, I see no point in limiting the content tag, people can still
navigate to remote sites by using javascript as long as the remote url is
whitelisted with the appropriate allow-navigation tag. They just need a
window.location = 'https://remoteurl.com';


El mar., 22 oct. 2019 a las 18:56, Norman Breau ()
escribió:

> There are some things I definitely disagree with in your list of
> responses. I do think
> the enterprise setup is enough of a reason to not add any kind of
> deprecation notice as I originally proposed. So I concede on the idea of
> deprecating this usage of the feature.
>
> I however do still think, a note on this should be documented in the
> config.xml docs as I think many users are not building enterprise apps,
> but still use remote urls for production apps.
>
> #1 is definitely TOS breaking. Code from a remote source must not be a
> requirement for the app, read: "Apps may contain or run code that is not
> embedded in the binary (e.g. HTML5-based games, bots, etc.), as long as
> code distribution isn’t the main purpose of the app"
>
> Code that isn't bundled with the app can only use capabilities available
> in the standard webkit view. Read "(2) only uses capabilities available
> in a standard WebKit view (e.g. it must open and run natively in Safari
> without modifications or additional software)". Google Play also has
> similar text in their policies.
>
> I also fail to understand how a developer can use a remote html page for
> their app index page and still avoid a blank page due to the device not
> having a data connection.
>
> So for these reasons, I think it still should be documented as bad
> practice for production apps at the very least. Of course, it can made
> clear that this note only applies to apps intended to be distributed to
> the app stores.
>
> On 2019-10-22 1:24 p.m., Jesse wrote:
> > Also, please keep in mind that there are other ways to distribute apps.
> > A company/developer with an enterprise license can build apps for
> > company/employee use and distribute them as they see fit.
> >
> >
> > On Tue, Oct 22, 2019 at 9:20 AM Jesse  wrote:
> >
> >> This is a crucial feature for development tools, and a valid production
> >> use case.
> >>
> >> 1. This is NOT breaking TOS with Apple, unless the developer decides to
> >> significantly change their app, which is bad practice anyway.
> >> 2. Care should be taken in what you deliver to your app, this is not
> >> cordova's concern.
> >> 3. Apps should provide 'some' offline experience, and not show a 404 of
> >> course, but that is up to the developer.
> >> 4. Yes, developers should be aware of this.
> >> 5. This is not 'repacking a website' you are missing the point, this is:
> >> 'making a purpose built web-app that you can make minor tweaks to
> without
> >> having to submit to app stores repeatedly, and to do some heavy lifting
> on
> >> the server.'  Some notable apps that are examples of this: Amazon,
> Walmart,
> >> Apple Music, Apple App Store, ...
> >>
> >>
> >>
> >>
> >> On Tue, Oct 22, 2019 at 9:05 AM julio cesar sanchez <
> >> jcesarmob...@gmail.com> wrote:
> >>
> >>> The content tag is also used for pointing to local development servers
> and
> >>> benefit from live reloading, so how do you plan to deprecate it only
> for
> >>> remote urls?
> >>>
> >>> El mar., 22 oct. 2019 a las 17:46, Norman Breau (<
> nor...@normanbreau.com
> >>>> )
> >>> escribió:
> >>>
> >>>> This is an extension of the issue I raised for adding warnings to the
> >>>> documentation which can be found at
> >>>> https://github.com/apache/cordova-docs/issues/1022
> >>>>
> >>>> In my opinion there are several reasons why using a remote url (such
> as
> >>>> https://myserver.com/) to host a cordova app is bad practice.
> >>>>
> >>>> 1. If your app uses native APIs, you're breaking the terms of service
> of
> >>>> the Apple and Google Play app stores. See Section 2.5.2 Software
> >>>> Requirements of apples guidelines.[1]
> >>>>
> >>>> 2. Extending onto #1, it makes the app must more easier to become
> >>>> vulnerable to exploits, because any other
> >>>> third party code loaded onto the 

Re: [DISCUSS] Deprecation of allowing remote urls in config's

[julio cesar sanchez]

The content tag is also used for pointing to local development servers and
benefit from live reloading, so how do you plan to deprecate it only for
remote urls?

El mar., 22 oct. 2019 a las 17:46, Norman Breau ()
escribió:

> This is an extension of the issue I raised for adding warnings to the
> documentation which can be found at
> https://github.com/apache/cordova-docs/issues/1022
>
> In my opinion there are several reasons why using a remote url (such as
> https://myserver.com/) to host a cordova app is bad practice.
>
> 1. If your app uses native APIs, you're breaking the terms of service of
> the Apple and Google Play app stores. See Section 2.5.2 Software
> Requirements of apples guidelines.[1]
>
> 2. Extending onto #1, it makes the app must more easier to become
> vulnerable to exploits, because any other
> third party code loaded onto the website may have access to the cordova
> APIs.
>
> 3. Apple & Google expects your app to be able to launch and "work"
> without a data connection. If your index file is
> remote, then your app cannot load to provide the user proper feedback
> that they require an internet connection. (See section 2.1 App
> Completeness & 4.2 Minimum Functionality apple guidelines)[1].
>
> 4. Using a remote URL generally causes a lot of CORs related issues when
> using non-standard protocols such as cdvfile:// (see
> https://github.com/apache/cordova-plugin-file/issues/352)
>
> 5. Even if your app does not use native APIs, and it's just repackaging
> a website, this goes against section 4.2 on apples policy[1].
>
> I don't exactly know how popular using  is,
> but I do see it frequent enough on reported issues. This is kind of
> frightening.
>
> So given the reasons I listed above, I think allowing remote sources in
> the  tag should be deprecated, and eventually removed in the
> future, of course allowing time for developers to refactor their app to
> bundle their code within the app.
>
> Sources:
> [1] https://developer.apple.com/app-store/review/guidelines/#design
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [DISCUSS] Cordova Plugin In-App-Browser release

[julio cesar sanchez]

I think it has a pretty importan issue fixed ( not working at all on iOS 13
if using WKWebView), so we should release as soon as possible, we can
always do another release in the future with more PRs if they get merged.


El mar., 15 oct. 2019 a las 21:30, Chris Brody ()
escribió:

> It is my understanding that we should get a few more PRs reviewed and
> merged before making the release.
>
> Niklas please feel free to ping us if you don't hear back anytime soon.
>
> On Tue, Oct 15, 2019 at 2:39 PM julio cesar sanchez
>  wrote:
> >
> > +1
> >
> > The release process is documented here
> >
> https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md
> >
> > But I've never tried, so not sure if everything is up to date.
> >
> > El mar., 15 oct. 2019 a las 19:51, Niklas Merz ()
> > escribió:
> >
> > > Hi everyone,
> > >
> > > I just wanted to start a dicussion here for a new release of the IAB
> > > plugin. Some people including myself who did two PRs recently are
> > > waiting for a new official release.
> > >
> > > Specifically see here:
> > > https://github.com/apache/cordova-plugin-inappbrowser/pull/534
> > >
> > > I am not sure what has to be done for a new release but I am happy to
> > > help. Thank you very much.
> > >
> > > Kind regards
> > >
> > > Niklas
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [DISCUSS] Cordova Plugin In-App-Browser release

[julio cesar sanchez]

+1

The release process is documented here
https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md

But I've never tried, so not sure if everything is up to date.

El mar., 15 oct. 2019 a las 19:51, Niklas Merz ()
escribió:

> Hi everyone,
>
> I just wanted to start a dicussion here for a new release of the IAB
> plugin. Some people including myself who did two PRs recently are
> waiting for a new official release.
>
> Specifically see here:
> https://github.com/apache/cordova-plugin-inappbrowser/pull/534
>
> I am not sure what has to be done for a new release but I am happy to
> help. Thank you very much.
>
> Kind regards
>
> Niklas
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: vote: PR merge convention

[julio cesar sanchez]

Sorry if it wasn't clear, I said I was leaving the protecting master branch
out of the vote.

Looks like we all agree on using "Squash and merge" as default, unless it
makes more sense to use one of the other options.

El jue., 3 oct. 2019 a las 3:43, Bryan Ellis () escribió:

> -1 for protected master branches.
> Protecting a branch is a great idea except it does not work with our
> current workflow process. COHO commits directly onto the master branch for
> releases. We would have to spend more time planning and changing our entire
> current workflow process to eliminate direct commits if we wanted to
> protect branches. There is alternative such keeping master open for direct
> commits and development while creating a protected "production" branch.
> Anyways this part of the discussion is off-topic and could be another
> discussion... Anyways, stated above I am downvoting protected branches for
> now.
>
> +1 for "Squash and merge"
> Makes a nice single commit with the PR number and without the extra merge
> commit.
>
> +1 for "Rebase and merge"
> There are use cases where this can work perfectly.
> For example, Cordova-Electron has a `draft-2.0.0` branch which is targeting
> the next major release. Major PRs were merged into that branch with "Squash
> and merge". This means all PRs have nice PR# information in the title.
> A PR will later be created to merge this branch onto master. "Rebase and
> merge" will be used and will not create the merge commit message and will
> not squash.
>
> -1 for "Create a merge commit"
> Not in favor of the extra merge commit. I think in most cases one PR should
> focus on one task so that means it could be squashed when there are
> multiple commits. If "Create a merge commit" is used, each commit will be
> merged and does not contain the PR# in the title. When creating release
> notes, I need to manually review those commits to identify what PR it came
> from to include the PR linking. Some times, depending on if they are all
> related commits, I need to manually group them and create a meaningful
> title for the release notes which I would prefer to have been done
> beforehand.
>
>
> On Wed, Oct 2, 2019 at 12:51 AM Jesse  wrote:
>
> > -1 for protected master branches, we are a small group of committers and
> > don't need rules to keep us honest.
> > Protecting master would involve infra, as we cannot manage the minutia in
> > github.  I think we all do this anyway except for rare occasions.
> >
> > +1 for squash and merge, as long as the meaningful individual commit
> > messages get consolidated into the 1 commit.
> >
> > On Tue, Oct 1, 2019 at 8:36 AM Norman Breau 
> > wrote:
> >
> > > +1 to protect the master branch.
> > >
> > > Forcing PR will help organize commits if we need to go back in
> > > time to determine the reason why a change was made as the
> > > commit in github will show the corresponding PR. Which will
> > > (hopefully) be properly filled out with context and motivation,
> > > as well as the issues that the PR resolves.
> > >
> > > +1 for "squash + merge" as a default strategy.
> > >
> > > I feel like most of the time having all the individual commits that
> > > makes up a PR is not really necessary. Most of the time it's
> > > bloated with tweaks fixing errors that was introduced during the
> > > development of the PR or perhaps refactoring for code style, etc.
> > > If there are instances where squash shouldn't be used, that can
> > > be decided on a per-case basis in my opinion.
> > >
> > > On 2019-10-01 10:37 a.m., Chris Brody wrote:
> > > > I would agree that "squash + merge" should be used in *most* cases,
> > > > and I think there is no dispute on this point.
> > > >
> > > > In the few cases where there are too many things for a "squash +
> > > > merge" commit, and we have the changes down to a limited number of
> > > > clean, sensible commits, then I would favor merging with a merge
> > > > commit that shows the PR number.
> > > >
> > > > My issue with "rebase and merge" is that the commit history would not
> > > > show the PR number.
> > > >
> > > > I think that having the commits show the PR number would make it a
> > > > little easier for whoever makes the release to make the release notes
> > > > with the PR numbers.
> > > >
> > > > Are there any recent examples of  "a lot of commits from 

vote: PR merge convention

[julio cesar sanchez]

Last year, Jan started a thread with different topics and one of them was
to have a merge convention. I copy the text:

> 3. Merge Conventions / Protected Branch:

> Connected to all that is my suggestion to protect the `master` branch so
that by default nobody can commit there - all changes have to be made via
Pull Requests. Pull Requests are by default merged via the "Squash + Merge"
button / functionality so that all commits are squashed into one clean
commit per change. This also enforces the commit message structure I posted
above. (Of course committers can choose to _not_ use Squash + Merge if
appropriate for the PR - e.g. when cherry picking commits from a release
branch or similar).

> What do you think about this suggestion?

Looks like we didn't agree on anything, but can we agree now?

I've checked a few repos and some of them have a lot of commits from the
same PR with meaningless commit messages when changes were requested, plus
the ugly "merge PR ### from YYY" that makes the commit history hard to
follow and hard to cherry pick if needed.

Since I'm not sure if we can protect branches, I'll focus only on the merge
convention.

Can we all agree on using the "squash + merge" for user PRs, unless we
think the different commits makes sense, in this case we should try the
"rebase and merge" button.

I vote +1

Re: Sponsorship of maintenance work on Cordova?

[julio cesar sanchez]

Since Cordova is an Apache project, I don't think we can apply to tidelift,
we should ask first.

For individuals there are the mentioned github sponsors, patreon, searching
a company willing to pay a person to work on the project, and probably more
that I'm not aware of.


El mié., 25 sept. 2019 a las 20:59, Chris Brody ()
escribió:

> Thanks Julio. I just tried the link and was told to join a waitlist:(
>
> Similar results from Tidelift at this time:
>
>- https://tidelift.com/lifter/search/npm/cordova-android
>- https://tidelift.com/lifter/search/npm/cordova-ios
>- https://tidelift.com/lifter/search/npm/cordova-cli
>- https://tidelift.com/lifter/search/npm/cordova-lib
>- https://tidelift.com/lifter/search/npm/cordova-common
>
> I think this kind of sponsorship is pretty badly needed in order to keep up
> with competitive frameworks such as Capacitor and React Native which *do*
> seem to have strong corporate backing and other advantages such as:
>
>- no need to wait for a non-standard "device ready" event
>- easy-to-understand MIT licensing terms
>
> I do think that Apache Cordova continues to have some major advantages to
> offer including:
>
>- Cordova seems to have *much less* JavaScript and native code per
>platform than Capacitor and React Native
>- Cordova has an extremely strong user community and would be in a very
>strong position to drive standardization of plugin APIs, in a similar
>fashion to the way that Node.js drives its N-API that works across
> itself
>and Electron
>
> Given these advantages, I would really hate to see Cordova die out due to a
> lack of resources so badly needed.
>
> Without sponsorship, I am in a position to contributed *very limited time*
> to
> help with the backlog.
>
> If sponsored, I may not be the most "affordable", but I do think my years
> of experience could provide some excellent value for the entire user
> community.
>
> Thanks and best regards,
>
> Chris Brody
>
> https://www.linkedin.com/in/chrisbrody/
>
> https://chrisbrody.com/
>
> On Thu, May 23, 2019 at 12:06 PM julio cesar sanchez <
> jcesarmob...@gmail.com>
> wrote:
>
> > Maybe you/they can apply here https://github.com/sponsors
> >
> >
> > El mié., 10 abr. 2019 a las 18:27, Chris Brody ()
> > escribió:
> >
> > > This wonderful project is maintained by a bunch of hard-working
> > > volunteers. I think the worst issue is that not enough time is devoted
> > > to the much needed bug fixes, dependency updates, documentation, and
> > > other maintenance work needed.
> > >
> > > At the same time there is plenty of talent available to do this kind
> > > of work if sponsored. I am also available for short-term projects of
> > > this nature. I am unfortunately not able to continue with active
> > > maintenance for free at this time.
> > >
> > > Given the level of industrial usage I think it should be no problem to
> > > find and manage the corporate sponsorship that could really help keep
> > > Cordova at a consistently top-notch quality level.
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> > >
> >
>

Re: UIWebView/WKWebView Migration Strategy for Cordova iOS

[julio cesar sanchez]

So Jesse, did you get a chance to look into this?

I think the pr has plenty of information and 2 clear options, should we now
vote on them?

El mié., 4 sept. 2019 a las 21:33, Jesse ()
escribió:

> Thanks for starting this Darryl. I will be digging into this more this week
> and I will reply in the pr.
>
> On Tue, Sep 3, 2019 at 4:56 PM Darryl Pogue  wrote:
>
> > Background: As of August 2019, Apple is now showing a deprecation
> > warning when uploading apps to the App Store that include
> > UIWebView-related code. As a result, all Cordova apps built for iOS
> > receive this deprecation warning on upload.
> >
> > We need to determine how Cordova as a project wants to proceed to
> > solve this problem. There are pull requests already being opened that
> > I'm quite concerned with end up breaking all existing Cordova apps,
> > and I think we want to be more careful about that.
> >
> > I've put together a document in the cordova-discuss repo outlining
> > some options for discussion:
> > https://github.com/apache/cordova-discuss/pull/110
> >
> > It might be easiest to keep all discussion on the GitHub PR for
> > consistency and bring it back to the mailing list for consensus on
> > next steps.
> >
> > ~Darryl
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>

Re: Cordova App crashes in iOS 12.4

[julio cesar sanchez]

Sorry, this mail list is not to help people with bugs or problems, it's to
discuss the Cordova project development.

By the look of it, it's crashing when showing a modal view, so think on
plugins or other parts of your app that present a native modal view and try
to narrow it down, otherwise the issue will be closed as it doesn't contain
enough information.


El mar., 10 sept. 2019 a las 7:56, Alexandru Ghioroae (<
alexandru.ghior...@evolutionfinance.com>) escribió:

> I am an engineer from WalletHub, a Cordova app that is also one of the
> highest-rated personal finance apps on the U.S. App Store (
> https://apps.apple.com/us/app/wallethub/id1110552982).
>
> We've been noticing a problem happening with our app lately on iPads in iOS
> 12.4 to which I've submitted an issue here:
> https://github.com/apache/cordova-ios/issues/665 . This came after we just
> released a new build updating to the latest platform and plugins, although
> I can see the issue coming on the older build as well but at a much lower
> rate. We were wondering if you could help us get to the bottom of it.  The
> crash rate on the iPad is really high and so this is very urgent for us.
>
> Any help you can provide would be much appreciated!
>

Re: [DISCUSS] Dropping support for Node 8

[julio cesar sanchez]

This was discussed already and I think everybody agreed to drop it.

Some people agreed, but said we should wait until December.

I've checked telemetry and node 8 is ~18% of users, but going down.

El lun., 9 sept. 2019 a las 16:38, Darryl Pogue ()
escribió:

> +1 from me
>
>
> On Mon, Sep 9, 2019 at 7:20 AM Norman Breau 
> wrote:
> >
> > Just starting a thread here to whether or not we should drop support for
> > Node 8 at the same time of dropping Node 6 support.
> > The original thought for this I believe is to avoid having to have 2
> > major version bumps as Node 8 EOL is in December 2019, only a few months
> > away.
> >
> > Personally I don't see why we should keep support something that is in
> > maintenance mode and is coming to the end of life soon, so I think
> > dropping Node 8 is a good idea.
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Cordova 9.X - minimal supported Android API-Levels / Android version?

[julio cesar sanchez]

Please, don’t use the mail list to ask questions, the list is to talk about
the development of  the Apache cordova project.

But answering your question, the supported Android versions don’t depend on
the Cordova (CLI) version, but on the cordova-android (platform) version.
Latest cordova-android is 8.x.x, so that table is up to date.

El El mar, 20 ago 2019 a las 1:34, Pavel Kvasnička <
pavel.kvasni...@seznam.cz> escribió:

> Hi,
>
>
>
> could You please let mem know minimal supported Android API-Levels /
> Android
> version of Cordova 9.X.
>
>
>
> This information is not in table on page
> https://cordova.apache.org/docs/en/latest/guide/platforms/android/
>
> There is only minimal supported API level for Cordova 8.X.
>
>
>
> Thanks, Pavel
>
>
>
>
>
>
>
>
>
>

Re: [DISCUSS] [Github Issues] Issue and PR template + Merge Conventions / Protected Branch

[julio cesar sanchez]

As it looks like we didn't agree in the squash + merge, can we agree now?
Or should I create a new thread to discuss it again?


El jue., 23 ago. 2018 a las 16:24, Jan Piotrowski ()
escribió:

> Here is the PR on GitHub templates, our usage of them and actual
> drafts for all templates:
> https://github.com/apache/cordova-contribute/pull/3
>
> Please keep all further discussion on the issue and pull request
> template in this Pull Request. Thank you.
> Am Di., 21. Aug. 2018 um 20:21 Uhr schrieb :
> >
> > Sounds pretty good to me. A few thoughts:
> >
> > - The support question template should refer people to a proper support
> > site like Stack Overflow.
> > - Merge convention should be: if multiple commits make the history more
> > meaningful, do a merge commit, else squash and rebase.
> > - the templates will probably require different information to be
> provided,
> > depending on the repository. cordova-lib is usually platform independent,
> > for example.
> >
> > Shazron  schrieb am Mi., 8. Aug. 2018, 06:52:
> >
> > > Agree with all 3 points by Jan.
> > >
> > > @Chris Brody I think we should make use of Github Milestones to track
> > > related issues.
> > > On Wed, Aug 8, 2018 at 6:59 AM Jan Piotrowski 
> > > wrote:
> > > >
> > > > Update to my initial email:
> > > >
> > > > I just noticed we actually _do_ have an issue template in use in the
> > > > cordovs-docs repository:
> > > >
> > >
> https://github.com/apache/cordova-docs/blob/master/.github/ISSUE_TEMPLATE.md
> > > >
> > > > J
> > > >
> > > > 2018-08-07 23:18 GMT+02:00 julio cesar sanchez <
> jcesarmob...@gmail.com>:
> > > > > I think us as committers should decide if the commits make sense to
> > > keep
> > > > > all of them or squash them into one. But bug fixes should usually
> be
> > > only
> > > > > one commit, and major refactors are not usually sent by non
> committers
> > > > >
> > > > > El El mar, 7 ago 2018 a las 23:02, Chris Brody <
> chris.br...@gmail.com>
> > > > > escribió:
> > > > >
> > > > >> > > I would favor a place where a contributor can mark if s/he
> would
> > > > >> > > recommend the committer should *not* use the squash option.
> > > > >> >
> > > > >> > That of course could be defined in the contributor guidelines
> or PR
> > > > >> > template (although there it might be a bit confusing to new
> users
> > > that
> > > > >> > don't know what this is talking about). Do you know how other
> > > project
> > > > >> > handle that?
> > > > >>
> > > > >> Haven't seen anything like this before.
> > > > >>
> > > > >> > In the end it is always the decision of the committer how
> > > contributed
> > > > >> > code makes it into the code base, so having good guidelines for
> us
> > > > >> > would probably be the best solution, right?
> > > > >>
> > > > >> Yes. General common sense may prove to be the major principle, as
> I
> > > > >> think it has in the past. For example:
> > > > >> * Someone raises a PR with bug fixes and major refactoring in
> separate
> > > > >> commits (should not be squashed)
> > > > >> * Someone else raises a PR with a single fix, but with extra
> commits
> > > > >> to fix issues with the first commit (*should* be squashed)
> > > > >>
> > > > >> I wonder if we can track these discussions in a better way,
> somehow. I
> > > > >> have no time to help with these things right now. I think better
> > > > >> tracking could help ensure these important tasks do not get
> forgotten.
> > > > >>
> > > > >>
> -
> > > > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > > >> For additional commands, e-mail: dev-h...@cordova.apache.org
> > > > >>
> > > > >>
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [Cordova dev] info needed label

[julio cesar sanchez]

For JIRA I think we agreed to close after 2 weeks with no response. Users
can reopen if they provide the info later.

El El lun, 15 jul 2019 a las 23:18, Darryl Pogue 
escribió:

> +1
>
> Might also be worth proposing a rule that issues tagged “info needed” get
> closed after X days if there is no information provided. We have a bunch of
> issues piling up that are all waiting for info, and we have no process that
> allows us to close those.
>
> On Mon, Jul 15, 2019 at 2:11 PM Jesse  wrote:
>
> > +1 I don't think you'll see any objections.
> >
> > On Mon, Jul 15, 2019 at 2:07 PM Chris Brody 
> wrote:
> >
> > > We receive a number of support issues where I think we need an
> > > explicit label such as “info needed”, to make it clear that more
> > > information is needed before we can provide any support. I think we
> > > need to add this label to a number of repos such as apache/cordova,
> > > cordova-android, cordova-ios, etc.
> > >
> > > Any objections if I would add this label to some of the repos on
> GitHub?
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> > >
> >
>

Re: Cordova ios with multiple targets

[julio cesar sanchez]

It’s a bug https://github.com/apache/cordova-ios/issues/538

El lunes, 17 de junio de 2019, Jesse  escribió:

> Hello Madhu,
>
> This is a channel for the development of Apache Cordova, and not a support
> mailing list.
> You can try asking on http://stackoverflow.com/questions/tagged/cordova or
> in our slack community at http://slack.cordova.io/
>
> Cheers,
>   Jesse
>
> On Sun, Jun 16, 2019 at 10:55 PM Madhusudhana rao Uppala <
> madhu.sudhan...@gmail.com> wrote:
>
> > Hi team,
> >
> > I have been trying to add watch kit extension to my ios project and able
> to
> > add successfully.
> > But the problem with build script when i try crating the ipa
> automatically
> > my build jaon replaces same bundle id for all the targets. So i need to
> > open xcode and place the correct provisioning profile to create the ipa
> but
> > i dont want to do it manually.
> >
> > Please help me is there any possibility to create ipa with build script
> > with multiple targets ?
> > --
> > Sent from iphone
> >
>

Re: Sponsorship of maintenance work on Cordova?

[julio cesar sanchez]

Maybe you/they can apply here https://github.com/sponsors


El mié., 10 abr. 2019 a las 18:27, Chris Brody ()
escribió:

> This wonderful project is maintained by a bunch of hard-working
> volunteers. I think the worst issue is that not enough time is devoted
> to the much needed bug fixes, dependency updates, documentation, and
> other maintenance work needed.
>
> At the same time there is plenty of talent available to do this kind
> of work if sponsored. I am also available for short-term projects of
> this nature. I am unfortunately not able to continue with active
> maintenance for free at this time.
>
> Given the level of industrial usage I think it should be no problem to
> find and manage the corporate sponsorship that could really help keep
> Cordova at a consistently top-notch quality level.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Best place to post questions about Cordova WKWebView support?

[julio cesar sanchez]

I don’t think there is a better place, but I definitely wouldn’t recommend
people asking on Cordova GitHub repositories, nor the dev list unless it’s
to talk about how we could try to fix or workaround those issues that
affect cordova-ios (if that was possible somehow).

The phonegap Google group has no activity anymore.

For quick answers probably the better place is the Cordova slack, but stack
Overflow should be better to not lose the answers in the future as slack
has a 1 message limit. Anyway, that assumes people uses the search
features on those sites, which is not always true.

Also, looks like Apple people seems to be more active on Twitter lately and
sometimes answer to people complaining about WebKit/WKWebView, but most
times they will tell you to file an issue so they can try to fix it. I
don’t really like when people use Twitter to complain about Cordova issues
instead of repotting them, so wouldn’t recommend it neither.


El jueves, 16 de mayo de 2019, Chris Brody  escribió:

> For issues with features such as XHR and DOM references?
>
> I can think of the following places:
>
> * https://github.com/apache/cordova-ios/issues
> * https://github.com/apache/cordova/issues
> * phone...@googlegroups.com
> * mailto: dev@cordova.apache.org (this forum)
> * StackOverflow (my experience with getting urgent, tough questions
> answered on StackOverflow has not been so good)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [DISCUSS] non-global Cordova installs

[julio cesar sanchez]

In Capacitor docs (from ionic), npx is user everywhere

 https://capacitor.ionicframework.com/

El jueves, 16 de mayo de 2019, Jesse  escribió:

> I think there is a disconnect on the actual proposal here.
>
> Here's the pr again ( keep the discussion here please )
> https://github.com/apache/cordova-docs/pull/987/files
>
> The only real use of npx as a one-off command would be the call to create a
> new app. ie. `npx cordova create dirname ...`
> The instructions after that are to cd into the dir, and install cordova
> locally.
> All npx calls after that are run from inside a project folder and are just
> the same as npm run commands, they access the binary exported in
> node_modules/cordova
>
> That said, I do still think npx should be presented as an alternative, and
> not necessarily the 'preferred' way.
>
>
>
>
>
>
> On Wed, May 15, 2019 at 10:38 PM Dmitry Blotsky 
> wrote:
>
> > In terms of exposure, btw, npx is indeed strictly worse than npm install.
> > It checks for dependencies, installs them, and runs them: all at every
> call
> > of a command. That is more frequent than how often anyone runs npm
> install,
> > and is more overhead than running a shell command directly.
> >
> > From a higher-up perspective though: every other software ecosystem gets
> > by with just running commands in a shell. How is our situation so
> > outlandish that the most time-tested tools don’t meet our command-running
> > needs?
> >
> > Dmitry
> >
> > > On May 15, 2019, at 22:29, Dmitry Blotsky 
> > wrote:
> > >
> > > If it’s any convincing data: none of React Native, Ionic, Angular,
> > Ember, Meteor, or Vue mention npx.
> > >
> > > They all recommend npm install -g or some variant using more mature
> > tools.
> > >
> > > I agree that it would be a piece of cake for us to instruct people to
> > install cordova for the local user, or to use per-project installs of
> > cordova. These options are all still pretty convenient, and don’t incur
> the
> > security penalties of npx.
> > >
> > > Dmitry
> > >
> > >> On May 15, 2019, at 02:15, Jesse  wrote:
> > >>
> > >> Given how contentious this has become, I think our best approach would
> > be
> > >> to continue with our global install expectation, and add documentation
> > on
> > >> a) what to do if you have issues with `npm i -g cordova` [1]
> > >> b) document how to do local dependencies and use npx ( this might be a
> > good
> > >> blog post as well as permanent documentation )
> > >>
> > >> Regarding some of the issues stated previously:
> > >>
> >  Dmitry: 1. It is strictly less secure than the status quo, and all
> > >> alternatives. ..
> > >> The exposure to the user is no different than `npm install -g`, it is
> > just
> > >> harder to know exactly what is happening.
> > >>
> >  Dmitry: 2. It is strictly less stable than a local installation ...
> > >> Only the first `npx cordova create ...` will result in a fetch,
> further
> > >> uses of npx cordova will use the cached version, and can be done
> > without a
> > >> network connection.
> > >>
> >  Darryl: Encouraging people to install Cordova globally causes issues
> > >> when working on multiple projects ...
> > >> Do we have a way of knowing how often this occurs? It sounds rare to
> me.
> > >> Regardless, there is no reason they can't go ahead install
> > cordova@version
> > >> as a dev dependency
> > >>
> > >> Personally, having read up on npx and done some basic tests, I am okay
> > with
> > >> it.  However, I also don't feel we have to force it on everyone.
> > >> We can suggest is as an alternative, and perhaps after we are all more
> > >> comfortable with it, it can become the default.
> > >>
> > >>
> > >> [1]
> > >>
> > https://docs.npmjs.com/resolving-eacces-permissions-
> errors-when-installing-packages-globally
> > >>
> > >>
> > >>
> > >>
> > >> On Tue, May 14, 2019 at 8:12 PM gandhi rajan  >
> > >> wrote:
> > >>
> > >>> Hi Dmitry,
> > >>>
> > >>> I second you on this.
> > >>>
> >  On Tuesday, May 14, 2019, Dmitry Blotsky 
> > wrote:
> > 
> >  I'm really glad this discussion lit up, because it clearly shows
> that
> > >>> this
> >  issue isn't settled.
> > 
> >  I personally have few opinions about the "best" solution here, but I
> >  firmly believe that npx is a non-starter for these 2 reasons:
> >  1. It is strictly less secure than the status quo, and all
> > alternatives.
> >  It is literally downloading code from hundreds of untrusted parties
> > and
> >  immediately running it. It's worse than piping a curl command into
> > bash
> > >>> (at
> >  least you can check the curl command's URL, or checksum the
> downloaded
> >  script).
> >  2. It is strictly less stable than a local installation because now
> > every
> >  call to Cordova goes through an opaque dependency.
> > 
> >  Unless both of those can be addressed, I think we shouldn't consider
> > npx.
> > 
> >  Dmitry
> > 
> > > On May 10, 2019, at 4:31 

Re: Re: [DISCUSS] Remove all documentation translations

[julio cesar sanchez]

+1

There was an older thread about it and somebody was opposed, but the time
has passed and nobody has tried to fix them and probably nobody knows the
process to make them work, so better kill them.

El mié., 15 may. 2019 a las 11:04, Toplak Daniel ()
escribió:

> +1
> I'm from germany and have read the some parts of the german docs, only one
> time.
> The quality was poor and not well translated, because maybe some
> translations were made automatically or by a person without the knowledge
> of every technical aspect of cordova.
> So I suggest to put the man power into a good english documentation,
> because this should be enough for each developer.
>
> Grüße / Regards
> Daniel Toplak
> Head of Mobile Development
>
> -Ursprüngliche Nachricht-
> Von: Niklas Merz 
> Gesendet: Mittwoch, 15. Mai 2019 11:00
> An: dev@cordova.apache.org
> Betreff: Re: [DISCUSS] Remove all documentation translations
>
> +1 I always use the English one because I cannot be sure the translated
> +ones are up to date
>
> Am 15. Mai 2019, 10:36, um 10:36, Jesse  schrieb:
> >+1
> >
> >@purplecabbage
> >risingj.com
> >
> >
> >On Wed, May 15, 2019 at 1:33 AM Hazem Saleh  wrote:
> >
> >> +1 on not maintaining these translated docs anymore.
> >>
> >> Thanks and Best Regards
> >>
> >> > On May 15, 2019, at 4:26 AM, Tim Brust
> >
> >> wrote:
> >> >
> >> > +1 for removing them
> >> >
> >> > Personally I've got the feeling that we can't maintain them while
> >> keeping a
> >> > good/high quality.
> >> >
> >> >> On Wed, May 15, 2019 at 10:24 AM  wrote:
> >> >>
> >> >> Doc translations are not being actively maintained and are thus
> >> outdated.
> >> >> Furthermore, at least some of the existing translations seem to be
> >> really
> >> >> bad too. Consequently I propose to remove all translations from
> >the docs
> >> >> (cordova-docs as well as any other repos).
> >> >>
> >> >> I checked the guide entry page
> >> >> 
> >in
> >> German
> >> >> and it's so horribly bad that it can be considered totally useless
> >IMO.
> >> >> OTOH, doing a Google translation of the English version yields a
> >really
> >> >> helpful and comprehensible text.
> >> >>
> >> >> Related Issues:
> >> >>
> >> >>
> >> >>   - https://github.com/apache/cordova/issues/29
> >> >>   - https://github.com/apache/cordova-docs/issues/995
> >> >>
> >> >> Cheers,
> >> >> Raphael
> >> >>
> >> >
> >> >
> >> > --
> >> > Tim Brust, Product Engineer
> >> >
> >> > tim.br...@sinnerschrader.com
> >> > T +49 40 398855 315
> >> >
> >> > SinnerSchrader Deutschland GmbH | SinnerSchrader Group
> >> > Völckersstraße 38, 22765 Hamburg, Germany
> >> >
> >> > Amtsgericht Hamburg HRB-Nr. 63663
> >> > Geschäftsführer: Matthias Schrader (Sprecher), Jürgen Alker, Dr.
> >> > Axel Averdung, Holger Blank, Thomas Dyckhoff, Dr. Lars Finke,
> >> > Martin Gassner, Peggy Hutchinson
> >> >
> >> > Büros: Berlin, Hamburg, Frankfurt a. M., München, Prag
> >> >
> >> > https://www.sinnerschrader.com | NEXT AGENCY
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >> For additional commands, e-mail: dev-h...@cordova.apache.org
> >>
> >>
>