So....how did this happen? (Git commit weirdness)

[Joe Bowser]

I haven't worked on Cordova in months, but for some reason I'm appearing on
this commit:

https://github.com/apache/cordova-android/commit/73692e60d81f49f148ba9f8b4bc230b2f4d968a4

Can someone explain how this happened?

Thanks

Joe

Re: vote duration discrepancy

[Joe Bowser]

I think security releases have shorter turnaround on votes fueled by the
desire to keep users safe from public disclosure and abuse, but even that
is rare.

On Fri., Sep. 28, 2018, 9:07 a.m. julio cesar sanchez, <
jcesarmob...@gmail.com> wrote:

> Yeah, I looked with git blame and the 48 hour message was 5 year old, so
> asking just in case Apache changed it and we missed it. Didn’t know it was
> decided that long ago.
>
> El El vie, 28 sept 2018 a las 17:45, Shazron  escribió:
>
> > FWIW the only reference I see for an emergency (security) patch vote
> > is here: https://httpd.apache.org/dev/voting.html#emergency for the
> > HTTP Server project.
> > However, that document is deemed obsolete. I believe it has been
> > superseded by the Security patch release process.
> > On Fri, Sep 28, 2018 at 11:41 PM Shazron  wrote:
> > >
> > > To be honest I didn't expect the vote to end so fast especially with
> > > the notice "Voting will go on for a minimum of 48 hours." in the vote
> > > thread itself.
> > > If this was expressed as a duration of 24 hours and expressed as an
> > > emergency (I know it was implied, but for some rules are rules), I
> > > think we would have been fine with that -- but the vote did say 48
> > > hours.On Fri, Sep 28, 2018 at 11:35 PM Shazron 
> > > wrote:
> > > >
> > > > Jesse sums up what I would have said. We all agreed on the 48 hours
> > > > (somewhere way back), especially with our project with 60+ repos
> where
> > > > we were changing rapidly (not so much now of course), and 72 hours
> was
> > > > too late for a release.
> > > >
> > > > 48 seems to be a good midpoint for the rule to include people from
> all
> > > > geographic timezones. 72 hours would have been OK if we only had to
> do
> > > > one release, like the http server project (that was the genesis of
> the
> > > > foundation itself..)
> > > > On Fri, Sep 28, 2018 at 11:21 PM Jesse 
> > wrote:
> > > > >
> > > > > These are guidelines. We make our own rules. The important part is
> > that we make sure we are inclusive of people all around the planet.
> > > > >
> > > > > A hotfix is a different situation, we need to get it out fast and
> > since it is not a significant change, a quick window should be fine.
> > > > >
> > > > > >  [1] ... Votes should generally be permitted to run for at least
> > 72 hours to provide an opportunity for all concerned persons to
> participate
> > regardless of their geographic locations. ...
> > > > >
> > > > > ‘Generally’!
> > > > > We shortened this for releases at some point, there is probably a
> > vote thread back there somewhere.
> > > > >
> > > > > Note that 72 hours still applies to votes nominating new
> > pmc/committers.
> > > > >
> > > > > Going deeper, I see a trend where we question process and rules. I
> > find this to be a distraction from the actual work. I am of the mind that
> > we are all trustworthy, able to constructively and openly discuss things
> > and this formality can be a barrier to moving forwards. Maybe newer
> > committers need clearer guidelines and I have just been around too long
> to
> > be objective, that is a possibility too.
> > > > >
> > > > > Cheers,
> > > > >   Jesse
> > > > >
> > > > > [1]
> >
> https://www.apache.org/foundation/votinhttps://www.apache.org/foundation/voting.html#ReleaseVotesg.html#ReleaseVotes
> > > > >
> > > > >
> > > > > > On Sep 28, 2018, at 1:56 AM, julio cesar sanchez <
> > jcesarmob...@gmail.com> wrote:
> > > > > >
> > > > > > This is being discussed in slack and github
> > > > > > , but I think
> > it belongs
> > > > > > to the mail list.
> > > > > >
> > > > > > There is a discrepancy in the duration of the votes.
> > > > > >
> > > > > > Apache states that:
> > > > > > Release votes SHOULD remain open for at least 72 hours.
> > > > > >
> > > > > > But in coho vote templates we have:
> > > > > > Voting will go on for a minimum of 48 hours.
> > > > > >
> > > > > > Also both of them say "at least" or "a minimum", but not sure if
> > sometimes
> > > > > > there can be exceptions to speed things up.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>

Stepping Back

[Joe Bowser]

Hey

As many people may be aware, I've moved on to another team at Adobe, so I
will no longer be able to be the primary maintainer of Cordova for Android,
and I won't be available to review any PRs in the future.  It's been an
interesting decade of development, and I'm thankful for all the people who
chose to try and build applications with PhoneGap/Cordova, even if it
wasn't the right choice for them.

Thanks

Joe Bowser

Re: deprecate weinre?

[Joe Bowser]

+1

On Sun., May 20, 2018, 8:48 a.m. julio cesar sanchez, <
jcesarmob...@gmail.com> wrote:

> Last release was in 7 Oct 2014, there is a lot of issues and nobody is
> working on them, and the even the weinre README.md talks about better
> inspectors, so, should we officially deprecate it and close all the pending
> issues?
>

Re: Add support for annotation @CordovaMethod

[Joe Bowser]

I'm fine with this.  The problem we have now with our extensive use of
reflection on Android is both with performance, as well as with being able
to use obfuscation tools like ProGuard, which many auditors want to use to
determine whether their code is "actually secure".  I don't think
obfuscation makes anything more secure at all, but I don't write these
security analyzers.  That's why I'm against adding more reflection into it.

Also, I've been doing this long enough to remember the old
addJavascriptInterface reflection exploit.



On Sun, Apr 29, 2018 at 2:43 PM, Wojciech Trocki <wtro...@gmail.com> wrote:

> I have created PR in Android repository to show idea.
>
> https://github.com/apache/cordova-android/pull/439
>
> This change do not use reflection/annotations mentioned in original
> proposition.
> IMHO with this change plugin interface will be much simpler and more object
> oriented.
>
> On Sun, Apr 29, 2018 at 4:55 PM, Rabindra Nayak <rabindra.mob...@gmail.com
> >
> wrote:
>
> > How about iOS annotation @CordovaMethod.Because the way Android and iOS
> and
> > other OS plugin implementation should be same.We need think that aspect.
> >
> >
> > On Sun, Apr 29, 2018, 21:08 Joe Bowser <bows...@gmail.com> wrote:
> >
> > > Cordova should be reducing the use of Reflection, not increasing it.  I
> > > don't think this is a good idea.
> > >
> > > On Sun, Apr 29, 2018, 8:28 AM Jesse, <purplecabb...@gmail.com> wrote:
> > >
> > > > I would like to see proof of value.
> > > > I believe the lookup of an action is insignificant compared to the
> > > message
> > > > conversion between js and native.
> > > > Please write some tests to justify your position.
> > > >
> > > >
> > > > > On Apr 29, 2018, at 7:59 AM, julio cesar sanchez <
> > > jcesarmob...@gmail.com>
> > > > wrote:
> > > > >
> > > > > I think it's a good idea.
> > > > >
> > > > > FYI, there is a plugin that already allows this, you just have to
> add
> > > it
> > > > as
> > > > > a dependency, but it's not backward compatible
> > > > > https://github.com/edewit/aerogear-reflect-cordova
> > > > >
> > > > > 2018-04-29 16:44 GMT+02:00 Wojciech Trocki <wtro...@redhat.com>:
> > > > >
> > > > >> Hi Maksim
> > > > >>
> > > > >> `if (METHOD_1.equals(action))` is very similar way to how redux
> > works.
> > > > >>
> > > > >> I have playing with your proposition to see how this could be
> > > > implemented.
> > > > >> What I found is that processing annotations on runtime can
> > contribute
> > > to
> > > > >> slower application startup due to fact that annotation needs to be
> > > > >> processed at runtime.
> > > > >> Deviceready event is delivered later, which is not desired. This
> > could
> > > > be
> > > > >> also processed on build time (something like dagger), but I did
> not
> > > > >> investigated that.
> > > > >>
> > > > >> I figured out simple way to extend this without any sacrifice on
> > > > >> performance.
> > > > >> This will simplify end user api and also still provide full
> > backwards
> > > > >> compatibility.
> > > > >> We could make improvement for developers without affecting end
> user
> > > app
> > > > >> performance.
> > > > >>
> > > > >> Linking gist with the idea:
> > > > >> https://gist.github.com/wtrocki/43bfdda18c086a3283bb8ba3bf2d052e
> > > > >>
> > > > >> Happy to contribute that back to the Cordova.
> > > > >>
> > > > >> *Note: *I'm not maintainer of Cordova Android platform so my
> > response
> > > do
> > > > >> not mean that there will be approval for this change.
> > > > >>
> > > > >>
> > > > >> On Sun, Apr 29, 2018 at 9:58 AM, chemeri...@gmail.com <
> > > > >> chemeri...@gmail.com>
> > > > >> wrote:
> > > > >>
> > > > >>> Hi guys. cordova-ios has a nice method binding for plugins.
> > > > Unfortunately
> > > > >>> cordova-android requires at present boilerplate implement

Re: Add support for annotation @CordovaMethod

[Joe Bowser]

Cordova should be reducing the use of Reflection, not increasing it.  I
don't think this is a good idea.

On Sun, Apr 29, 2018, 8:28 AM Jesse,  wrote:

> I would like to see proof of value.
> I believe the lookup of an action is insignificant compared to the message
> conversion between js and native.
> Please write some tests to justify your position.
>
>
> > On Apr 29, 2018, at 7:59 AM, julio cesar sanchez 
> wrote:
> >
> > I think it's a good idea.
> >
> > FYI, there is a plugin that already allows this, you just have to add it
> as
> > a dependency, but it's not backward compatible
> > https://github.com/edewit/aerogear-reflect-cordova
> >
> > 2018-04-29 16:44 GMT+02:00 Wojciech Trocki :
> >
> >> Hi Maksim
> >>
> >> `if (METHOD_1.equals(action))` is very similar way to how redux works.
> >>
> >> I have playing with your proposition to see how this could be
> implemented.
> >> What I found is that processing annotations on runtime can contribute to
> >> slower application startup due to fact that annotation needs to be
> >> processed at runtime.
> >> Deviceready event is delivered later, which is not desired. This could
> be
> >> also processed on build time (something like dagger), but I did not
> >> investigated that.
> >>
> >> I figured out simple way to extend this without any sacrifice on
> >> performance.
> >> This will simplify end user api and also still provide full backwards
> >> compatibility.
> >> We could make improvement for developers without affecting end user app
> >> performance.
> >>
> >> Linking gist with the idea:
> >> https://gist.github.com/wtrocki/43bfdda18c086a3283bb8ba3bf2d052e
> >>
> >> Happy to contribute that back to the Cordova.
> >>
> >> *Note: *I'm not maintainer of Cordova Android platform so my response do
> >> not mean that there will be approval for this change.
> >>
> >>
> >> On Sun, Apr 29, 2018 at 9:58 AM, chemeri...@gmail.com <
> >> chemeri...@gmail.com>
> >> wrote:
> >>
> >>> Hi guys. cordova-ios has a nice method binding for plugins.
> Unfortunately
> >>> cordova-android requires at present boilerplate implementation of
> method
> >>> execute:
> >>>
> >>> public class MyPlugin extends CordovaPlugin {
> >>>...
> >>>@Override
> >>>public boolean execute(String action, JSONArray args,
> CallbackContext
> >>> callbackContext) throws JSONException {
> >>>if (METHOD_1.equals(action)) {
> >>>method1(args, callbackContext);
> >>>} else if (METHOD_2.equals(action)) {
> >>>method2(args, callbackContext);
> >>>...
> >>>} else {
> >>>return false;
> >>>}
> >>>return true;
> >>>}
> >>>...
> >>> }
> >>>
> >>> I suggest to implement support for @CordovaMethod that will allow for
> >>> plugin authors to reduce boilerplate code, so the implementation above
> >> will
> >>> look like:
> >>>
> >>> public class MyPlugin extends CordovaPlugin {
> >>>...
> >>>@CordovaMethod
> >>>private void method1(JSONArray args, CallbackContext
> callbackContext)
> >>> throws JSONException {
> >>>...
> >>>}
> >>>
> >>>@CordovaMethod
> >>>private void method2(JSONArray args, CallbackContext
> callbackContext)
> >>> throws JSONException {
> >>>...
> >>>}
> >>>...
> >>> }
> >>>
> >>> Implementation of method execute in CordovaPlugin.java will check for
> >>> methods marked with @CordovaMethod and if action argument matches a
> >> method
> >>> with @CordovaMethod, the method will be invoked. Developer can also
> >> specify
> >>> action manually via the name parameter:
> >>>
> >>> public class MyPlugin extends CordovaPlugin {
> >>>...
> >>>@CordovaMethod(name = "method1")
> >>>private void myMethod(JSONArray args, CallbackContext
> >> callbackContext)
> >>> throws JSONException {
> >>>...
> >>>}
> >>>...
> >>> }
> >>>
> >>> Important to note that backward compatibility is preserved - old
> plugins
> >>> didn't have @CordovaMethod, but new ones can use it to simplify code.
> >>>
> >>> What do you think?
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >>> For additional commands, e-mail: dev-h...@cordova.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >> WOJCIECH TROCKI
> >>
> >> Red Hat Mobile 
> >>
> >> IM: wtrocki
> >> 
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: New Android Preference

[Joe Bowser]

Is there a PR ready for this to land?

On Fri, Apr 20, 2018 at 12:04 PM, Simon MacDonald  wrote:

> Hey all,
>
> I'd like to suggest that we add a new Android preference. It would be a
> boolean preference, to control whether or not to run the Google Services
> Plugin.
>
> A number of plugins need to have this gradle plugin run during build time
> and they are handling it via a gradle file included in their plugin like
> this:
>
> https://github.com/fechanique/cordova-plugin-fcm/blob/
> master/src/android/FCMPlugin.gradle
>
> but that falls down if two plugins try to apply GoogleServicesPlugin.
>
> The way to mitigate that right now is to have dependency on
> cordova-support-google-services so it will only run once.
>
> 
>
> However, it makes sense for this to be a preference in cordova-android.
> Perhaps,
>
> 
>
> If the value is true, then we apply the GoogleServicesPlugin.
>
> Simon Mac Donald
> http://simonmacdonald.com
>

Re: [DISCUSS] Android & iOS release

[Joe Bowser]

Looks good.  I'll do a quick sanity check later today, but it should be
fine.

On Wed, Apr 18, 2018 at 5:26 AM, julio cesar sanchez <jcesarmob...@gmail.com
> wrote:

> I've sent a PR for the Android Studio detection problem, it just makes
> isAndroidStudioProject return true, removed the non Android Studio
> tests/files (or updated some to be Android Studio tests)
> https://github.com/apache/cordova-android/pull/437
>
> That wont fix incompatible plugins, but at least will point to the bad one
> or the bad one won't work, instead of pointing to the next one to be
> installed.
>
> What I say about the mapping is we have a check for .java and .xml, and we
> copy those files to the new location, I don't think we should expect plugin
> authors to map other files, I'll try to send another PR for that when I
> have time, but if you feel we need to do a release before that, feel free
> to do it.
>
>
> 2018-04-18 0:03 GMT+02:00 Steven Gill <stevengil...@gmail.com>:
>
> > Joe or myself don't currently have the time to fix this problem and
> > probably won't for the foreseeable future. Plugin maintainers can send
> PRs
> > to cordova-android adding their mapping if they want or update their
> > plugins.
> >
> > But I'd like to get this release out because of the bug fixes that have
> > landed and because the release train should keep rolling. A future
> release
> > can happen with those fixes once PRs come in
> >
> > On Tue, Apr 17, 2018 at 2:59 PM, Joe Bowser <bows...@gmail.com> wrote:
> >
> > > On Tue, Apr 17, 2018 at 2:54 PM, julio cesar sanchez <
> > > jcesarmob...@gmail.com
> > > > wrote:
> > >
> > > > Yeah, but our plugins work because we have put some code to copy our
> > > files
> > > > to a new location instead of updating the paths in the plugins'
> > > plugin.xml.
> > > > This is handled for what our plugins need, but not for all the
> possible
> > > > cases, so I don't think it's ok to make a patch to just make our
> > plugins
> > > > work but don't do the same for other allowed files. If we didn't
> update
> > > the
> > > > core plugins for the new path we shouldn't ask users to do it in
> their
> > > > plugins.
> > > >
> > > >
> > > Fair, we should really be updating all our plugins and figuring out how
> > to
> > > remove the patch.  The last thing I want to see is this code growing
> like
> > > a cancer, which it very well could.  I don't think we should be
> delaying
> > > the release because of third party plugins not being able to be
> > installed.
> > >
> > >
> > > > Also there is the problem I told you about the false positive making
> it
> > > > think it's an Eclipse project and making our plugins fail to install
> if
> > > > they are installed after a plugin with the previos problem.
> > > >
> > > >
> > > Yeah, that's a pretty major failure that we never saw when we were
> > testing
> > > 7.0.  I don't think this should delay the release either unless a PR
> > > arrives that fixes this.
> > >
> > >
> > >
> > > >
> > > > 2018-04-17 23:30 GMT+02:00 Joe Bowser <bows...@gmail.com>:
> > > >
> > > > > I disagree.  We have our core plugins installing and uninstalling
> > > without
> > > > > issue currently, and we can't babysit everyone with their third
> party
> > > > > plugins.  The community needs to come up with a plan on deprecating
> > the
> > > > old
> > > > > project structure and communicating that to the third party plugin
> > > > > maintainers.
> > > > >
> > > > >
> > > > > On Tue, Apr 17, 2018 at 2:28 PM, julio cesar sanchez <
> > > > > jcesarmob...@gmail.com
> > > > > > wrote:
> > > > >
> > > > > > Before doing an Android release we should fix the problems with
> > > plugins
> > > > > > installs, people is not updating because of it
> > > > > >
> > > > > > 2018-04-17 3:31 GMT+02:00 gandhi rajan <gandhiraja...@gmail.com
> >:
> > > > > >
> > > > > > > Hi Steve,
> > > > > > >
> > > > > > > Can you please have a look at this PR -
> > > > > > > https://github.com/apache/cordova-docs/pull/811
> > > > > > >
> > > > > > > It's related to Cordova doc changes.
> > > > > > >
> > > > > > > On Tuesday, April 17, 2018, Steven Gill stevengil...@gmail.com
> >
> > > > wrote:
> > > > > > >
> > > > > > > > Going to aim to do a release this week. Let me know if there
> > are
> > > > any
> > > > > > PRs
> > > > > > > I
> > > > > > > > should look at.
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Regards,
> > > > > > > Gandhi
> > > > > > >
> > > > > > > "The best way to find urself is to lose urself in the service
> of
> > > > others
> > > > > > > !!!"
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Plugins release

[Joe Bowser]

Hey

This is technically off-topic, but I commented on the PR asking for a new
PR and discussion on the list.  However, without additional committers, I
don't see this happening in the short term.  If people are interested in
becoming committers on this project, people should let us know on this
mailing list.  We can definitely use the help.

I hope this clears things up a bit.



On Tue, Apr 17, 2018 at 11:27 AM, Niklas Merz  wrote:

> Hello everyone,
>
> I am watching another issue for some time and I would like to see it going
> forward.
>
> Cordova InAppBrowser WKWebview support
> https://issues.apache.org/jira/browse/CB-7179?page=com.atlas
> sian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel&
> focusedCommentId=16160433#comment-16160433
>
> Dave Alden did some great work and commented it, but now it seems stuck.
> How can we promote the effort to get WKWebview for the IAB plugin? Or is
> there no chance to get that in the official plugin?
>
> Thanks for your help.
>
> Best regards
> Niklas
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [DISCUSS] Android & iOS release

[Joe Bowser]

On Tue, Apr 17, 2018 at 2:54 PM, julio cesar sanchez <jcesarmob...@gmail.com
> wrote:

> Yeah, but our plugins work because we have put some code to copy our files
> to a new location instead of updating the paths in the plugins' plugin.xml.
> This is handled for what our plugins need, but not for all the possible
> cases, so I don't think it's ok to make a patch to just make our plugins
> work but don't do the same for other allowed files. If we didn't update the
> core plugins for the new path we shouldn't ask users to do it in their
> plugins.
>
>
Fair, we should really be updating all our plugins and figuring out how to
remove the patch.  The last thing I want to see is this code growing like
a cancer, which it very well could.  I don't think we should be delaying
the release because of third party plugins not being able to be installed.


> Also there is the problem I told you about the false positive making it
> think it's an Eclipse project and making our plugins fail to install if
> they are installed after a plugin with the previos problem.
>
>
Yeah, that's a pretty major failure that we never saw when we were testing
7.0.  I don't think this should delay the release either unless a PR
arrives that fixes this.



>
> 2018-04-17 23:30 GMT+02:00 Joe Bowser <bows...@gmail.com>:
>
> > I disagree.  We have our core plugins installing and uninstalling without
> > issue currently, and we can't babysit everyone with their third party
> > plugins.  The community needs to come up with a plan on deprecating the
> old
> > project structure and communicating that to the third party plugin
> > maintainers.
> >
> >
> > On Tue, Apr 17, 2018 at 2:28 PM, julio cesar sanchez <
> > jcesarmob...@gmail.com
> > > wrote:
> >
> > > Before doing an Android release we should fix the problems with plugins
> > > installs, people is not updating because of it
> > >
> > > 2018-04-17 3:31 GMT+02:00 gandhi rajan <gandhiraja...@gmail.com>:
> > >
> > > > Hi Steve,
> > > >
> > > > Can you please have a look at this PR -
> > > > https://github.com/apache/cordova-docs/pull/811
> > > >
> > > > It's related to Cordova doc changes.
> > > >
> > > > On Tuesday, April 17, 2018, Steven Gill stevengil...@gmail.com>
> wrote:
> > > >
> > > > > Going to aim to do a release this week. Let me know if there are
> any
> > > PRs
> > > > I
> > > > > should look at.
> > > > >
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > Gandhi
> > > >
> > > > "The best way to find urself is to lose urself in the service of
> others
> > > > !!!"
> > > >
> > >
> >
>

Re: [DISCUSS] Android & iOS release

[Joe Bowser]

I disagree.  We have our core plugins installing and uninstalling without
issue currently, and we can't babysit everyone with their third party
plugins.  The community needs to come up with a plan on deprecating the old
project structure and communicating that to the third party plugin
maintainers.


On Tue, Apr 17, 2018 at 2:28 PM, julio cesar sanchez  wrote:

> Before doing an Android release we should fix the problems with plugins
> installs, people is not updating because of it
>
> 2018-04-17 3:31 GMT+02:00 gandhi rajan :
>
> > Hi Steve,
> >
> > Can you please have a look at this PR -
> > https://github.com/apache/cordova-docs/pull/811
> >
> > It's related to Cordova doc changes.
> >
> > On Tuesday, April 17, 2018, Steven Gill stevengil...@gmail.com> wrote:
> >
> > > Going to aim to do a release this week. Let me know if there are any
> PRs
> > I
> > > should look at.
> > >
> >
> >
> > --
> > Regards,
> > Gandhi
> >
> > "The best way to find urself is to lose urself in the service of others
> > !!!"
> >
>

Re: [VOTE] Plugins Release (Attempt 2)

[Joe Bowser]

I vote +1

- Tested with Mobilespec

On Sun, Apr 15, 2018, 2:37 PM julio cesar sanchez, 
wrote:

> I vote +1
>
> 2018-04-13 22:08 GMT+02:00 Steven Gill :
>
> > Please review and vote on the release of this plugins release
> > by replying to this email (and keep discussion on the DISCUSS thread)
> >
> > Release issue: https://issues.apache.org/jira/browse/CB-14030
> >
> > The plugins have been published to
> > dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-14030/
> >
> > The packages were published from their corresponding git tags:
> > cordova-plugin-camera: 4.0.3 (6ce1443622)
> > cordova-plugin-vibration: 3.1.0 (0b323409f9)
> > cordova-plugin-statusbar: 2.4.2 (fbc4862dbd)
> > cordova-plugin-media-capture: 3.0.2 (288a47eee1)
> > cordova-plugin-inappbrowser: 3.0.0 (757022d85a)
> > cordova-plugin-globalization: 1.11.0 (65331146ca)
> > cordova-plugin-device: 2.0.2 (e83c1afd84)
> > cordova-plugin-battery-status: 2.0.2 (aebf1a1445)
> > cordova-plugin-device-motion: 2.0.1 (7aa654f673)
> > cordova-plugin-device-orientation: 2.0.1 (477eb2b52e)
> >
> > Upon a successful vote I will upload the archives to dist/, upload
> > them to npm, and post the corresponding blog post.
> >
> > Voting guidelines:
> >
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
> > How to vote on a plugins release at
> > https://github.com/apache/cordova-coho/blob/master/docs/
> > plugins-release-process.md#voting
> >
> > 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 repos were tagged
> >
>

Re: Fixed Locations for Build Artifacts?

[Joe Bowser]

I don't see this code as being worth maintaining, since Google often
changes build tools versions and we barely have the resources now to play
catch up.

On Mar. 11, 2018 8:05 p.m., "Terence M. Bandoian"  wrote:

> Would it make sense to copy build artifacts to fixed locations, with fixed
> names, and to publicize those locations and names for the use of downstream
> tools?  This would help avoid unnecessary breakages when the build tools
> used or the project structures generated by Cordova are modified.
>
> -Terence Bandoian
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [DISCUSS] cordova-android release

[Joe Bowser]

+1

On Feb 20, 2018 9:19 AM, "Jan Piotrowski"  wrote:

> +1 Looking good.
>
> 2018-02-20 19:53 GMT+01:00 Steven Gill :
> > Issue: https://issues.apache.org/jira/browse/CB-13912
> >
> > I'm thinking minor bump to 7.1.0. You can see the change log in the
> > comments of the issue
> >
> > On Sat, Feb 17, 2018 at 1:51 PM, Simon MacDonald <
> simon.macdon...@gmail.com>
> > wrote:
> >
> >> +1
> >>
> >> The change is super useful for Android 4.4 devices.
> >>
> >> On Fri, Feb 16, 2018 at 17:48 gandhi rajan 
> >> wrote:
> >>
> >> > +1
> >> >
> >> > On Saturday, February 17, 2018, Steven Gill 
> >> > wrote:
> >> >
> >> > > cordova-android release. Going to do a minor or patch release for
> >> > android.
> >> > > Any issues or concerns?
> >> > >
> >> >
> >> >
> >> > --
> >> > Regards,
> >> > Gandhi
> >> >
> >> > "The best way to find urself is to lose urself in the service of
> others
> >> > !!!"
> >> >
> >> --
> >> 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
>
>

Re: [VOTE] Plugins Release

[Joe Bowser]

I vote +1
* Ran through manual tests of camera, splashscreen, inappbrowser
* Ran mobilespec auto tests

On Thu, Jan 25, 2018 at 11:59 AM, Suraj Pindoria 
wrote:

> Please review and vote on the release of this plugins release
> by replying to this email (and keep discussion on the DISCUSS thread)
>
> Release issue: https://issues.apache.org/jira/browse/CB-13826
>
> The plugins have been published to dist/dev:
> https://dist.apache.org/repos/dist/dev/cordova/CB-13826/
>
> The packages were published from their corresponding git tags:
> cordova-plugin-file-transfer: 1.7.1 (8747b4018e)
> cordova-plugin-media: 5.0.2 (f90bac5f32)
> cordova-plugin-camera: 4.0.2 (4b276ee534)
> cordova-plugin-splashscreen: 5.0.2 (09e1f06fb0)
> cordova-plugin-inappbrowser: 2.0.2 (7eb2e1ea03)
>
> Upon a successful vote I will upload the archives to dist/, upload them to
> npm, and post the corresponding blog post.
>
> Voting guidelines:
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
> How to vote on a plugins release at
> https://github.com/apache/cordova-coho/blob/master/docs/
> plugins-release-process.md#voting
>
> 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
> * Ran mobilespec
>

[DISCUSS] Cordova-Android 7.1/7.0.1???

[Joe Bowser]

Hey

So, it doesn't look like there's been too many hiccups with the last major
release, but there does need to be an API bump, and there are issues with
android-versions not being updated causing the build to fail, so I do think
that we should do another Android release.  I'm not sure whether it should
be a 7.1 or a 7.0.1, since not a whole lot has changed.

What do people think?

Joe

Re: [DISCUSS] Plugins release

[Joe Bowser]

That's good for another release.  I still need to look at a fix for camera
for Android 8.0, but I'm fine with doing another release later.

On Mon, Jan 15, 2018 at 12:47 PM, Simon MacDonald  wrote:

> Hey all,
>
> I'd like to spin up a new plugins release soon. Even though the file
> transfer plugin has been deprecated there is an issue with the file
> dependency it uses which makes it hard for folks to upgrade other plugins
> in their app. That is if they are still using file transfer they are stuck
> with file plugin 5.0.0 and that prevents folks from using the latest media,
> media-capture or file plugins.
>
> As well there are some fixes in the Media plugin I'd like to get out.
>
> What other plugins besides:
>
> cordova-plugin-file-transfer
> cordova-plugin-media
>
> need a release?
>
> Simon Mac Donald
> http://simonmacdonald.com
>

Re: [DISCUSS] Plugins Release

[Joe Bowser]

Same, I would like to see everything pushed out before the new year.  With
the break and sabbaticals (Steve on Jan, me on Feb), I would like to see
things out when there's all hands on deck.

On Thu, Dec 14, 2017 at 9:03 PM, Simon MacDonald 
wrote:

> Yeah, let's get a plugin release out before a lot of us take off on
> vacation.
>
> Simon Mac Donald
> http://simonmacdonald.com
>
> On Thu, Dec 14, 2017 at 8:58 PM, Shazron  wrote:
>
> > The release train for plugins shouldn't be stopped since we do infrequent
> > releases. Plugins not on this train will be on the next one.
> >
> > On Fri, Dec 15, 2017 at 7:43 AM, Steven Gill 
> > wrote:
> >
> > > I was going to do whichever ones were ready. Want to get them out
> before
> > > the holidays. I'll review some prs for it today and aim to do a release
> > > tomorrow.
> > >
> > > Adobe is shutdown Dec 22 - Jan 2. I'm also going to be gone the month
> of
> > > January for Sabbatical.
> > >
> > > On Thu, Dec 14, 2017 at 2:09 PM, julio cesar sanchez <
> > > jcesarmob...@gmail.com
> > > > wrote:
> > >
> > > > All of them?
> > > >
> > > > I have this pending PR
> > > >  waiting
> > to
> > > be
> > > > merged, I was planning on doing it this weekend. It removes old iOS
> 6-7
> > > > code from statusbar plugin. And then I was planning on deprecating
> some
> > > of
> > > > StatusBar.styleLightContent, StatusBar.styleBlackTranslucent and
> > > > StatusBar.styleBlackOpaque as all 3 of them do the exact same thing
> > now.
> > > >
> > > > This one  >
> > > > about
> > > > adding browser support looks interesting, but somebody with more
> > > experience
> > > > in browser platform should review it.
> > > >
> > > > I was also planning on removing some code (the deprecated
> UIAlertView)
> > > from
> > > > dialogs plugin.
> > > >
> > > >
> > > >
> > > > 2017-12-14 22:52 GMT+01:00 Steven Gill :
> > > >
> > > > > Any issues with me doing a plugins release?
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] cordova@8 & tools release

[Joe Bowser]

+1

This is a really good idea, and it would be great to have a new tools
release before the end of the year to fix some of the hiccups that we had
with the Cordova-Android 7.0 release.

On Tue, Dec 12, 2017 at 10:52 AM, Steven Gill 
wrote:

> Working on getting out a tools release
>
> Doing cordova@8 because we are dropping support for blackberry, webos,
> Ubuntu.
>
> Also aiming to remove `--no-fetch` in this release and drop npm dependency
> from cordova.
>
> Lastly, `cordova save` command will be dropped in this release too
>
> Any thoughts or feedback?
>

Re: [VOTE] 7.0.0 Android Release - November 30, 2017

[Joe Bowser]

The vote has now closed. The results are:

Positive Binding Votes: (# of PMC members that +1'ed)
Joe Bowser
Simon Macdonald
Vishal Mishra

The vote has passed.



On Thu, Nov 30, 2017 at 5:04 PM, Vishal Mishra <vismi...@adobe.com.invalid>
wrote:

> I vote +1:
>
> * Ran coho audit-license-headers over the relevant repos
> * Created a sample app with cordova-android 7.0.0 as a platform and added
> various plugins.
> * Ran gradlew test
> * Ran coho check-license to ensure all dependencies have Apache-compatible
> licenses
>
> Vishal Mishra
>
>
>
> On 11/30/17, 1:08 PM, "Simon MacDonald" <simon.macdon...@gmail.com> wrote:
>
> 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
> * Created test app with cordova-android 7.0.0 as platform
> * Ran gradlew test
> * Ran gradlew connectedAndroidTest
>
>
> Simon Mac Donald
> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fsimonmacdonald.com=02%7C01%7Cvismishr%40adobe.com%
> 7C649326bc409a41fb2e8508d5383694a9%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636476729426504804=WK29z0fOhY5ZGbOwr%
> 2F8CpkgNZ8S9s1CkMvIaw%2BWvOZQ%3D=0
>
> On Thu, Nov 30, 2017 at 2:30 PM, Joe Bowser <bows...@gmail.com> wrote:
>
> > Please review and vote on this 7.0.0 Android Release
> > by replying to this email (and keep discussion on the DISCUSS thread)
> >
> > Release issue: https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCB-
> 13620=02%7C01%7Cvismishr%40adobe.com%7C649326bc409a41fb2e8508d53836
> 94a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636476729426504804=5ESkZZtpDu7sIrO3gfBKefs9O9t33o
> D4F1v0zIr3IV4%3D=0
> >
> > The archive has been published to
> > dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-13620
> >
> > The package was published from its corresponding git tag:
> > cordova-android: 7.0.0 (4b06eecf3e)
> >
> > Note that you can test it out via:
> >
> > cordova platform add https://na01.safelinks.
> protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
> 2Fapache%2Fcordova-android%237.0.0=02%7C01%7Cvismishr%40adobe.com%
> 7C649326bc409a41fb2e8508d5383694a9%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636476729426504804=4fcuSMT4%
> 2B4hAgCcV9OsJeeNwgwyxlm5ECQd9Fay8jYo%3D=0
> >
> > Upon a successful vote I will upload the archive to dist/, publish it
> > to npm, and post the blog post.
> >
> > Voting guidelines:
> > https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgithub.com%2Fapache%2Fcordova-coho%2Fblob%2Fmaster%2Fdocs%
> 2Frelease-voting.md=02%7C01%7Cvismishr%40adobe.com%
> 7C649326bc409a41fb2e8508d5383694a9%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636476729426514812=P%2FPCupqRpWiPJvg4nRq4Ypaj8YH1ji
> jyWrttGkUk%2Ft4%3D=0
> >
> > 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
> >
>
>
>

[VOTE] 7.0.0 Android Release - November 30, 2017

[Joe Bowser]

Please review and vote on this 7.0.0 Android Release
by replying to this email (and keep discussion on the DISCUSS thread)

Release issue: https://issues.apache.org/jira/browse/CB-13620

The archive has been published to
dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-13620

The package was published from its corresponding git tag:
cordova-android: 7.0.0 (4b06eecf3e)

Note that you can test it out via:

cordova platform add https://github.com/apache/cordova-android#7.0.0

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

Re: [DISCUSS] Cordova-Android 7.0.0

[Joe Bowser]

Hey

I was wrong.  We actually skip two steps in the testing process.  Do not
test upgrading.  Upgrading is now simply removing the old platform and
adding the new one.  If you are using a standalone workflow, you should
probably migrate your changes over manually.  Apologies for this, the
release document doesn't have the updated info for upgrading your version
of Android.


On Thu, Nov 30, 2017 at 9:55 AM, Joe Bowser <bows...@gmail.com> wrote:

> Hey
>
> A reminder when testing, we have deprecated the update script for
> standalone projects.  Step 5 will most likely fail becuase we're changing
> the structure.  We've agreed to deprecate that script, since it has already
> been deprecated for iOS and Windows.
>
> https://github.com/apache/cordova-coho/blob/master/docs/
> platforms-release-process.md
>
> Other than that, keep testing the release the same way that the release
> will be tested.  The Vote thread will be incoming.
>
>
> On Wed, Nov 29, 2017 at 9:58 AM, Joe Bowser <bows...@gmail.com> wrote:
>
>> StudioProjectCompat has been merged.  I think we should start the release
>> process ASAP.
>>
>> On Wed, Nov 29, 2017 at 2:36 AM, Jan Piotrowski <piotrow...@gmail.com>
>> wrote:
>>
>>> Thanks Joe and Darryl, makes sense and sounds good.
>>>
>>> I'm looking forward to the merge and getting some more eyeballs (and
>>> projects with all their different plugins...) on it. Having a "modern"
>>> project structure is really great.
>>>
>>> -J
>>>
>>> 2017-11-29 1:36 GMT+01:00 Darryl Pogue <dvpdin...@gmail.com>:
>>> > I believe we can do published beta or rc builds, so long as they are
>>> > considered releases and follow the usual rules for a published
>>> > release. They would be releases, but with a -beta.1 or -rc.1 suffix on
>>> > the version number.
>>> >
>>> > We probably don't have to do that through: As Joe says, it's a major
>>> > version bump and existing projects will not automatically upgrade.
>>> > Versions that are saved into config.xml or package.json automatically
>>> > use ^ or ~ restrictions to ensure that major version bumps will not
>>> > happen without manual intervention.
>>> >
>>> > One thing to be aware of though is that cordova-cli (or one of its
>>> > dependencies) has an internal list of "compatible" versions and will
>>> > install those versions by default. So even if we published v7.0.0 next
>>> > week, end users would need to specifically ask for it until the CLI
>>> > has been updated and published.
>>> >
>>> >
>>> > Release details aside, I did a quick test of the PR with my latest
>>> > project (albeit with no plugins) and it all seemed to work. One thing
>>> > that we'll need to mention in docs/blog is that resource-file and
>>> > edit-config tags in config.xml will need to be updated to the new
>>> > paths.
>>> >
>>> > On Tue, Nov 28, 2017 at 4:26 PM, Joe Bowser <bows...@gmail.com> wrote:
>>> >> On Tue, Nov 28, 2017 at 3:35 PM, Jan Piotrowski <piotrow...@gmail.com
>>> >
>>> >> wrote:
>>> >>
>>> >>> Is there any "beta" release process defined (7.0.0-beta?) that could
>>> >>> be used to get more feedback? Maybe create a blog post with
>>> >>> instructions on how to test this beta version?
>>> >>> I can't even imagine all the variations on how people out there are
>>> >>> using all this and what could go wrong.
>>> >>>
>>> >>>
>>> >> There's no beta release process.  The official release is the official
>>> >> release, and we test it the best we can and send it out to the world
>>> after
>>> >> a series of release candidates, all of which happens out in the
>>> open.  The
>>> >> ASF release process in it's entirety is here, which includes the
>>> discussion
>>> >> about dev builds:
>>> >>
>>> >> http://www.apache.org/legal/release-policy.html
>>> >>
>>> >> In addition to that, we currently do our best to adhere to semver to
>>> >> indicate what sort of release we're trying to do.
>>> >>
>>> >> https://semver.org/
>>> >>
>>> >> It's this adherence to semver that kept a bunch of these PRs sitting
>>> around
>>> >> in the

Re: [DISCUSS] Cordova-Android 7.0.0

[Joe Bowser]

Hey

A reminder when testing, we have deprecated the update script for
standalone projects.  Step 5 will most likely fail becuase we're changing
the structure.  We've agreed to deprecate that script, since it has already
been deprecated for iOS and Windows.

https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md

Other than that, keep testing the release the same way that the release
will be tested.  The Vote thread will be incoming.


On Wed, Nov 29, 2017 at 9:58 AM, Joe Bowser <bows...@gmail.com> wrote:

> StudioProjectCompat has been merged.  I think we should start the release
> process ASAP.
>
> On Wed, Nov 29, 2017 at 2:36 AM, Jan Piotrowski <piotrow...@gmail.com>
> wrote:
>
>> Thanks Joe and Darryl, makes sense and sounds good.
>>
>> I'm looking forward to the merge and getting some more eyeballs (and
>> projects with all their different plugins...) on it. Having a "modern"
>> project structure is really great.
>>
>> -J
>>
>> 2017-11-29 1:36 GMT+01:00 Darryl Pogue <dvpdin...@gmail.com>:
>> > I believe we can do published beta or rc builds, so long as they are
>> > considered releases and follow the usual rules for a published
>> > release. They would be releases, but with a -beta.1 or -rc.1 suffix on
>> > the version number.
>> >
>> > We probably don't have to do that through: As Joe says, it's a major
>> > version bump and existing projects will not automatically upgrade.
>> > Versions that are saved into config.xml or package.json automatically
>> > use ^ or ~ restrictions to ensure that major version bumps will not
>> > happen without manual intervention.
>> >
>> > One thing to be aware of though is that cordova-cli (or one of its
>> > dependencies) has an internal list of "compatible" versions and will
>> > install those versions by default. So even if we published v7.0.0 next
>> > week, end users would need to specifically ask for it until the CLI
>> > has been updated and published.
>> >
>> >
>> > Release details aside, I did a quick test of the PR with my latest
>> > project (albeit with no plugins) and it all seemed to work. One thing
>> > that we'll need to mention in docs/blog is that resource-file and
>> > edit-config tags in config.xml will need to be updated to the new
>> > paths.
>> >
>> > On Tue, Nov 28, 2017 at 4:26 PM, Joe Bowser <bows...@gmail.com> wrote:
>> >> On Tue, Nov 28, 2017 at 3:35 PM, Jan Piotrowski <piotrow...@gmail.com>
>> >> wrote:
>> >>
>> >>> Is there any "beta" release process defined (7.0.0-beta?) that could
>> >>> be used to get more feedback? Maybe create a blog post with
>> >>> instructions on how to test this beta version?
>> >>> I can't even imagine all the variations on how people out there are
>> >>> using all this and what could go wrong.
>> >>>
>> >>>
>> >> There's no beta release process.  The official release is the official
>> >> release, and we test it the best we can and send it out to the world
>> after
>> >> a series of release candidates, all of which happens out in the open.
>> The
>> >> ASF release process in it's entirety is here, which includes the
>> discussion
>> >> about dev builds:
>> >>
>> >> http://www.apache.org/legal/release-policy.html
>> >>
>> >> In addition to that, we currently do our best to adhere to semver to
>> >> indicate what sort of release we're trying to do.
>> >>
>> >> https://semver.org/
>> >>
>> >> It's this adherence to semver that kept a bunch of these PRs sitting
>> around
>> >> in the GitHub repo for way too damn long (a lot of those old PRs were
>> from
>> >> July and August!), because we need to keep master ready for a security
>> >> release.  The fact that we're releasing a Cordova-Android 7.0.0 is an
>> >> indication that things will break.  People are under no obligation to
>> >> immediately upgrade their existing codebases to this, many third party
>> >> plugins will most likely break in the short term, and technically we're
>> >> supposed to be supporting 6.4.x for six months after this release,
>> although
>> >> that's contingent on active contributors (we need people to own
>> processes).
>> >>
>> >> The last major Cordova-Android release was 6.0.0, back in

Re: [DISCUSS] Cordova-Android 7.0.0

[Joe Bowser]

StudioProjectCompat has been merged.  I think we should start the release
process ASAP.

On Wed, Nov 29, 2017 at 2:36 AM, Jan Piotrowski <piotrow...@gmail.com>
wrote:

> Thanks Joe and Darryl, makes sense and sounds good.
>
> I'm looking forward to the merge and getting some more eyeballs (and
> projects with all their different plugins...) on it. Having a "modern"
> project structure is really great.
>
> -J
>
> 2017-11-29 1:36 GMT+01:00 Darryl Pogue <dvpdin...@gmail.com>:
> > I believe we can do published beta or rc builds, so long as they are
> > considered releases and follow the usual rules for a published
> > release. They would be releases, but with a -beta.1 or -rc.1 suffix on
> > the version number.
> >
> > We probably don't have to do that through: As Joe says, it's a major
> > version bump and existing projects will not automatically upgrade.
> > Versions that are saved into config.xml or package.json automatically
> > use ^ or ~ restrictions to ensure that major version bumps will not
> > happen without manual intervention.
> >
> > One thing to be aware of though is that cordova-cli (or one of its
> > dependencies) has an internal list of "compatible" versions and will
> > install those versions by default. So even if we published v7.0.0 next
> > week, end users would need to specifically ask for it until the CLI
> > has been updated and published.
> >
> >
> > Release details aside, I did a quick test of the PR with my latest
> > project (albeit with no plugins) and it all seemed to work. One thing
> > that we'll need to mention in docs/blog is that resource-file and
> > edit-config tags in config.xml will need to be updated to the new
> > paths.
> >
> > On Tue, Nov 28, 2017 at 4:26 PM, Joe Bowser <bows...@gmail.com> wrote:
> >> On Tue, Nov 28, 2017 at 3:35 PM, Jan Piotrowski <piotrow...@gmail.com>
> >> wrote:
> >>
> >>> Is there any "beta" release process defined (7.0.0-beta?) that could
> >>> be used to get more feedback? Maybe create a blog post with
> >>> instructions on how to test this beta version?
> >>> I can't even imagine all the variations on how people out there are
> >>> using all this and what could go wrong.
> >>>
> >>>
> >> There's no beta release process.  The official release is the official
> >> release, and we test it the best we can and send it out to the world
> after
> >> a series of release candidates, all of which happens out in the open.
> The
> >> ASF release process in it's entirety is here, which includes the
> discussion
> >> about dev builds:
> >>
> >> http://www.apache.org/legal/release-policy.html
> >>
> >> In addition to that, we currently do our best to adhere to semver to
> >> indicate what sort of release we're trying to do.
> >>
> >> https://semver.org/
> >>
> >> It's this adherence to semver that kept a bunch of these PRs sitting
> around
> >> in the GitHub repo for way too damn long (a lot of those old PRs were
> from
> >> July and August!), because we need to keep master ready for a security
> >> release.  The fact that we're releasing a Cordova-Android 7.0.0 is an
> >> indication that things will break.  People are under no obligation to
> >> immediately upgrade their existing codebases to this, many third party
> >> plugins will most likely break in the short term, and technically we're
> >> supposed to be supporting 6.4.x for six months after this release,
> although
> >> that's contingent on active contributors (we need people to own
> processes).
> >>
> >> The last major Cordova-Android release was 6.0.0, back in October 2016,
> >> when we changed the default bridge.  A more accurate example of a major
> >> release would be Cordova-Android 5.0.0, when permissions were brought
> in,
> >> or Cordova-Android 4.0.0, when we first added support for Crosswalk and
> >> other Third Party WebViews. (i.e. GeckoView, tencent, etc).  We try and
> >> only do a major release annually, and given the fact that Android
> Studio is
> >> an unstable moving target, this was sorely needed.
> >>
> >> I'm going to merge in the PR tomorrow morning and see how many people
> are
> >> watching master and not the list.
> >>
> >> -J
> >>>
> >>>
> >>> 2017-11-29 0:03 GMT+01:00 Joe Bowser <bows...@gmail.com>:
> >>> > Comments on the PR are good 

Re: [DISCUSS] Cordova-Android 7.0.0

[Joe Bowser]

On Tue, Nov 28, 2017 at 3:35 PM, Jan Piotrowski <piotrow...@gmail.com>
wrote:

> Is there any "beta" release process defined (7.0.0-beta?) that could
> be used to get more feedback? Maybe create a blog post with
> instructions on how to test this beta version?
> I can't even imagine all the variations on how people out there are
> using all this and what could go wrong.
>
>
There's no beta release process.  The official release is the official
release, and we test it the best we can and send it out to the world after
a series of release candidates, all of which happens out in the open.  The
ASF release process in it's entirety is here, which includes the discussion
about dev builds:

http://www.apache.org/legal/release-policy.html

In addition to that, we currently do our best to adhere to semver to
indicate what sort of release we're trying to do.

https://semver.org/

It's this adherence to semver that kept a bunch of these PRs sitting around
in the GitHub repo for way too damn long (a lot of those old PRs were from
July and August!), because we need to keep master ready for a security
release.  The fact that we're releasing a Cordova-Android 7.0.0 is an
indication that things will break.  People are under no obligation to
immediately upgrade their existing codebases to this, many third party
plugins will most likely break in the short term, and technically we're
supposed to be supporting 6.4.x for six months after this release, although
that's contingent on active contributors (we need people to own processes).

The last major Cordova-Android release was 6.0.0, back in October 2016,
when we changed the default bridge.  A more accurate example of a major
release would be Cordova-Android 5.0.0, when permissions were brought in,
or Cordova-Android 4.0.0, when we first added support for Crosswalk and
other Third Party WebViews. (i.e. GeckoView, tencent, etc).  We try and
only do a major release annually, and given the fact that Android Studio is
an unstable moving target, this was sorely needed.

I'm going to merge in the PR tomorrow morning and see how many people are
watching master and not the list.

-J
>
>
> 2017-11-29 0:03 GMT+01:00 Joe Bowser <bows...@gmail.com>:
> > Comments on the PR are good for a line-by-line.  This e-mail thread is
> > basically to decide whether to go ahead with the release process, which
> is
> > indicated in excruciating detail here:
> >
> > https://github.com/apache/cordova-coho/blob/master/docs/
> platforms-release-process.md
> >
> > I'll be merging this in tomorrow morning (was going to be later today,
> but
> > I don't like merging when the CI isn't green) and anyone who is pulling
> > directly from master should be seeing these changes.
> >
> > On Tue, Nov 28, 2017 at 2:15 PM, Jan Piotrowski <piotrow...@gmail.com>
> > wrote:
> >
> >> Thanks Darryl, seems I scrolled over the comments a bit too fast .
> >>
> >> Just installed locally with cordova 7.1.0 and seems to work fine!
> >>
> >>
> >> Here is a Github repo with what I did:
> >> https://github.com/janpio/cordova-android7test
> >>
> >>
> >> There are two branches you can compare:
> >> https://github.com/janpio/cordova-android7test/compare/
> >> cordova-android@6.4.0...cordova-android@7.0.0
> >> which only shows _how much_ changed and a direct comparison is useless.
> >>
> >> Better to compare visually by going through the folder structure:
> >> https://github.com/janpio/cordova-android7test/tree/
> >> cordova-android%406.4.0/platforms/android
> >> https://github.com/janpio/cordova-android7test/tree/
> >> cordova-android%407.0.0/platforms/android
> >>
> >>
> >> APKs seems to be _much_ smaller now:
> >> https://github.com/janpio/cordova-android7test/blob/
> >> cordova-android%406.4.0_with_build/platforms/android/build/
> >> outputs/apk/debug/android-debug.apk
> >> vs.
> >> https://github.com/janpio/cordova-android7test/blob/
> >> cordova-android%406.4.0_with_build/platforms/android/build/
> >> outputs/apk/debug/android-debug.apk
> >> Unzipping the APKs shows that mainly the content of /res is much
> >> smaller now and cordova.js contains another
> >> PLATFORM_VERSION_BUILD_LABEL - everything else is identical.
> >>
> >>
> >> Android Studio is happy with the project and can build it via Gradle.
> >> It also shows the Manifest file in the default view now as the
> >> structure is recognized.
> >>
> >>
> >> Really nice how painless testing this was. Thanks Joe.
> >>
> >> Questions and feedback here on 

Re: [DISCUSS] Cordova-Android 7.0.0

[Joe Bowser]

Comments on the PR are good for a line-by-line.  This e-mail thread is
basically to decide whether to go ahead with the release process, which is
indicated in excruciating detail here:

https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md

I'll be merging this in tomorrow morning (was going to be later today, but
I don't like merging when the CI isn't green) and anyone who is pulling
directly from master should be seeing these changes.

On Tue, Nov 28, 2017 at 2:15 PM, Jan Piotrowski <piotrow...@gmail.com>
wrote:

> Thanks Darryl, seems I scrolled over the comments a bit too fast .
>
> Just installed locally with cordova 7.1.0 and seems to work fine!
>
>
> Here is a Github repo with what I did:
> https://github.com/janpio/cordova-android7test
>
>
> There are two branches you can compare:
> https://github.com/janpio/cordova-android7test/compare/
> cordova-android@6.4.0...cordova-android@7.0.0
> which only shows _how much_ changed and a direct comparison is useless.
>
> Better to compare visually by going through the folder structure:
> https://github.com/janpio/cordova-android7test/tree/
> cordova-android%406.4.0/platforms/android
> https://github.com/janpio/cordova-android7test/tree/
> cordova-android%407.0.0/platforms/android
>
>
> APKs seems to be _much_ smaller now:
> https://github.com/janpio/cordova-android7test/blob/
> cordova-android%406.4.0_with_build/platforms/android/build/
> outputs/apk/debug/android-debug.apk
> vs.
> https://github.com/janpio/cordova-android7test/blob/
> cordova-android%406.4.0_with_build/platforms/android/build/
> outputs/apk/debug/android-debug.apk
> Unzipping the APKs shows that mainly the content of /res is much
> smaller now and cordova.js contains another
> PLATFORM_VERSION_BUILD_LABEL - everything else is identical.
>
>
> Android Studio is happy with the project and can build it via Gradle.
> It also shows the Manifest file in the default view now as the
> structure is recognized.
>
>
> Really nice how painless testing this was. Thanks Joe.
>
> Questions and feedback here on the list or better as comments in the PR?
>
> -J
>
> 2017-11-28 21:43 GMT+01:00 Darryl Pogue <dvpdin...@gmail.com>:
> > The steps here should work:
> > https://github.com/apache/cordova-android/pull/389#
> issuecomment-320067936
> >
> > To recap on email, you'll want to add the android platform via a git
> reference:
> >
> > cordova platform add
> > git://github.com/infil00p/cordova-android.git#StudioProjectCompat
> >
> > On Tue, Nov 28, 2017 at 12:24 PM, Jan Piotrowski <piotrow...@gmail.com>
> wrote:
> >>
> >> Awesome!
> >>
> >> For reference, you are talking about
> >> https://github.com/apache/cordova-android/pull/389, correct?
> >>
> >> What can I / one do to test this locally?
> >>
> >> -J
> >>
> >> 2017-11-28 19:53 GMT+01:00 Joe Bowser <bows...@gmail.com>:
> >> > Hey
> >> >
> >> > I'm going to merge in StudioProjectCompat into Master today.  Once
> that's
> >> > done, I'd like to get the next major version of Cordova out so that
> there's
> >> > not a crazy difference between master and the released versions of
> >> > Cordova.  This release will have the new structure for Android Studio
> >> > projects, which in the future will be easier to maintain, and will
> allow
> >> > for people to experiment with writing Cordova Android plugins in
> Koltin. (I
> >> > haven't tried, because I need this to land before I can do that).
> >> >
> >> > I've wrapped up all the PRs on cordova-android  except for that one,
> and
> >> > I've put everything up until this point in 6.4.x as well, since 6.4.0
> will
> >> > be the last 6.x version before this release comes out.
> >> >
> >> > As far as Crosswalk, this does once again break Crosswalk, but
> Crosswalk
> >> > has been discontinued by the original maintainers.  That said, in
> theory
> >> > once the fix is made in the Crosswalk repo, it should in theory be
> able to
> >> > work with the new structure.
> >> >
> >> > Also, this release will be bumping up the supported API Version to
> Android
> >> > 4.4, or API Level 19.
> >> >
> >> > This will hopefully be the last major release of Cordova Android, but
> it
> >> > comes with a LOT of much needed updates and fixes (i.e. Adopting Java
> 8).
> >> >

[DISCUSS] Cordova-Android 7.0.0

[Joe Bowser]

Hey

I'm going to merge in StudioProjectCompat into Master today.  Once that's
done, I'd like to get the next major version of Cordova out so that there's
not a crazy difference between master and the released versions of
Cordova.  This release will have the new structure for Android Studio
projects, which in the future will be easier to maintain, and will allow
for people to experiment with writing Cordova Android plugins in Koltin. (I
haven't tried, because I need this to land before I can do that).

I've wrapped up all the PRs on cordova-android  except for that one, and
I've put everything up until this point in 6.4.x as well, since 6.4.0 will
be the last 6.x version before this release comes out.

As far as Crosswalk, this does once again break Crosswalk, but Crosswalk
has been discontinued by the original maintainers.  That said, in theory
once the fix is made in the Crosswalk repo, it should in theory be able to
work with the new structure.

Also, this release will be bumping up the supported API Version to Android
4.4, or API Level 19.

This will hopefully be the last major release of Cordova Android, but it
comes with a LOT of much needed updates and fixes (i.e. Adopting Java 8).
If this doesn't get released, we're going to forever be bogged down with
legacy code.  It's been extremely hard to get as much feedback on this one,
so more feedback is appreciated.

Thanks

Joe

Re: [VOTE] Plugins Release Nov 6, 2017

[Joe Bowser]

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
* Ran mobilespec on Android


On Tue, Nov 7, 2017 at 3:56 PM, Audrey So  wrote:

> 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
> * Added/removed plugins successfully on hello world app
>
>
>
>
>
> On 11/6/17, 4:47 PM, "Steven Gill"  wrote:
>
> >Please review and vote on the release of this plugins release
> >by replying to this email (and keep discussion on the DISCUSS thread)
> >
> >Release issue: https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCB-
> 13542=02%7C01%7C%7C79be3d4758654a06bf6808d525794081%
> 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456125059190144=
> BfyawxPhwkYmEw8aNV5RCG8Dy9uf3baYzZ4ivq756%2Bo%3D=0
> >
> >The plugins have been published to
> >dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-13542/
> >
> >The packages were published from their corresponding git tags:
> >cordova-plugin-battery-status: 1.2.5 (e336730d4b)
> >cordova-plugin-camera: 3.0.0 (d456eeb711)
> >cordova-plugin-contacts: 3.0.0 (a4d5e28e74)
> >cordova-plugin-device: 1.1.7 (6d2011ba02)
> >cordova-plugin-dialogs: 1.3.4 (10887f4026)
> >cordova-plugin-file-transfer: 1.7.0 (c9ac8e1b3e)
> >cordova-plugin-file: 5.0.0 (8568babcc0)
> >cordova-plugin-geolocation: 3.0.0 (a168c04b33)
> >cordova-plugin-globalization: 1.0.8 (a99c829800)
> >cordova-plugin-inappbrowser: 1.7.2 (b9c577044c)
> >cordova-plugin-media: 4.0.0 (ad484202f5)
> >cordova-plugin-media-capture: 2.0.0 (ea934aa267)
> >cordova-plugin-network-information: 1.3.4 (0cdf5d1999)
> >cordova-plugin-splashscreen: 4.1.0 (326f13220e)
> >cordova-plugin-statusbar: 2.3.0 (655f6cb1da)
> >cordova-plugin-screen-orientation: 2.0.2 (8a8f8562cb)
> >cordova-plugin-vibration: 2.1.6 (ab73db1943)
> >cordova-plugin-whitelist: 1.3.3 (d10c82486f)
> >cordova-plugin-wkwebview-engine: 1.1.4 (9fb282e2dd)
> >cordova-plugin-test-framework: 1.1.6 (dfe4e84453)
> >
> >Upon a successful vote I will upload the archives to dist/, upload
> >them to npm, and post the corresponding blog post.
> >
> >Voting guidelines:
> >https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgithub.com%2Fapache%2Fcordova-coho%2Fblob%2Fmaster%2Fdocs%
> 2Frelease-voting.md=02%7C01%7C%7C79be3d4758654a06bf6808d525794081%
> 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636456125059190144=
> RcCwyes6xVvMwiyL91XBDhurzm9xdi%2FNtVqhRjO7qs4%3D=0
> >How to vote on a plugins release at
> >https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgithub.com%2Fapache%2Fcordova-coho%2Fblob%2Fmaster%2Fdocs%
> 2Fplugins-release-process.md%23voting=02%7C01%7C%
> 7C79be3d4758654a06bf6808d525794081%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636456125059190144=AhozWWZ1I9UhDzgBESbvUl8FhuptOv
> ltYTYGD53%2Bp%2FM%3D=0
> >
> >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
> >* Ran mobile-spec
>

Re: [Vote] 6.4.0 Android Release

[Joe Bowser]

The vote has now closed. The results are:

Positive Binding Votes: (# of PMC members that +1'ed)

Joe Bowser
Suraj Pindora
Audrey So
Steven Gill

The vote has passed.

On Wed, Nov 8, 2017 at 2:08 PM, Steven Gill <stevengil...@gmail.com> wrote:

> I vote +1:
> * Ran coho verify-archive
> * Created hello world app & and deployed to device
> * ran npm test
>
> On Wed, Nov 8, 2017 at 1:59 PM, Audrey So <a...@adobe.com.invalid> wrote:
>
> > 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
> > * Created hello world app & was able to add/ rm, build/run successfully
> to
> > emulator
> > * Npm test (passed)
> >
> >
> >
> >
> >
> > On 11/8/17, 1:50 PM, "Suraj Pindoria" <pindoria.su...@gmail.com> wrote:
> >
> > >I vote +1:
> > >
> > >* Ran npm test, all greens
> > >* Created hello-world and successfully deployed to emulator and device
> > >
> > >On Mon, Nov 6, 2017 at 3:44 PM, Joe Bowser <bows...@gmail.com> wrote:
> > >
> > >> Please review and vote on this 6.4.0 Android Release
> > >>
> > >> by replying to this email (and keep discussion on the DISCUSS thread)
> > >>
> > >> Release issue: https://na01.safelinks.protection.outlook.com/?url=
> > https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCB-
> > 15328=02%7C01%7C%7C7ef3146720f64801841808d526f2cf99%
> > 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636457746667246255=
> > KdNZwan2KSTZyr7h4FWDFjay%2BMXZFiSVBRmY7gTigHs%3D=0
> > >>
> > >> The archive has been published to dist/dev:
> > >> https://na01.safelinks.protection.outlook.com/?url=
> > https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%
> > 2Fcordova%2FCB-15328=02%7C01%7C%7C7ef3146720f64801841808d526f2cf99%
> > 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636457746667246255=
> > cdg1bNexFkAsm8z6pbiLcFXVbxT8hWOIi27UNW7t2u0%3D=0
> > >>
> > >> The package was published from its corresponding git tag:
> > >> cordova-android: 6.4.0 (7a27ee4f69)
> > >>
> > >> Note that you can test it out via:
> > >>
> > >> cordova platform add https://na01.safelinks.
> > protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
> > 2Fapache%2Fcordova-android%236.4.0=02%7C01%7C%
> > 7C7ef3146720f64801841808d526f2cf99%7Cfa7b1b5a7b34438794aed2c178de
> > cee1%7C0%7C0%7C636457746667246255=V4eSZvvNwyCt7VnF3oGcPdJfNHfH1A
> > m86tiFkc3fYcE%3D=0
> > >>
> > >> Upon a successful vote I will upload the archive to dist/, publish it
> to
> > >> npm, and post the blog post.
> > >>
> > >> Voting guidelines:
> > >> https://na01.safelinks.protection.outlook.com/?url=
> > https%3A%2F%2Fgithub.com%2Fapache%2Fcordova-coho%2Fblob%2Fmaster%2Fdocs%
> > 2Frelease-voting.md=02%7C01%7C%7C7ef3146720f64801841808d526f2cf99%
> > 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636457746667246255=
> > pWKuOK95S2kEwumzjqU1jRxkQ3IjpOznjO3QghcB0Xg%3D=0
> > >>
> > >> 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
> > >>
> >
>

[Vote] 6.4.0 Android Release

[Joe Bowser]

Please review and vote on this 6.4.0 Android Release

by replying to this email (and keep discussion on the DISCUSS thread)

Release issue: https://issues.apache.org/jira/browse/CB-15328

The archive has been published to dist/dev:
https://dist.apache.org/repos/dist/dev/cordova/CB-15328

The package was published from its corresponding git tag:
cordova-android: 6.4.0 (7a27ee4f69)

Note that you can test it out via:

cordova platform add https://github.com/apache/cordova-android#6.4.0

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

[DISCUSS] Cordova-Android 6.4.0 Release

[Joe Bowser]

I just merged in the fix for compiling with the latest Gradle Android
tools/Android Studio.  I think we need to do a release fairly quickly so
that people can use the latest version of Android to build their projects.

Any thoughts on this before we go ahead with a vote thread?

[Announce] Cordova Android@6.3.0 released

[Joe Bowser]

Blog:
http://cordova.apache.org/announcements/2017/09/27/android-release.html
Twitter: https://twitter.com/apachecordova/status/914924937302892544

Re: [Vote] 6.3.0 Android Release

[Joe Bowser]

The vote has now closed. The results are:

Positive Binding Votes: 3
Joe Bowser
Steven Gill
Audrey So

The vote has passed

On Wed, Sep 27, 2017 at 1:22 PM, Audrey So <a...@adobe.com.invalid> wrote:

> I vote +1:
>
> * Added to a hello world project & added plugins, build successful
> * Ran npm test, passing
> * coho audit-license-headers
> * coho verify-archieve
> * Ran mobilespec on emulator
>
>
>
>
>
> On 9/27/17, 10:53 AM, "Steven Gill" <stevengil...@gmail.com> wrote:
>
> >I vote +1:
> >
> >* Ran npm test
> >* Added to a hello world project, added plugins
> >* ran coho verify-archive
> >
> >On Mon, Sep 25, 2017 at 2:25 PM, Joe Bowser <bows...@gmail.com> wrote:
> >
> >> Please review and vote on this 6.3.0 Android Release
> >> by replying to this email (and keep discussion on the DISCUSS thread)
> >>
> >> Release issue: https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCB-=02%7C01%7C%
> 7C3b81ab94c1ca42f4e82608d505d0c8b1%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636421316685318137=U70eZNTMo4PCPTC78cY%
> 2F6CrgkK9CDRU0IMRj2FdloEM%3D=0
> >>
> >> The archive has been published to
> >> dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-
> >>
> >> The package was published from its corresponding git tag:
> >> cordova-android: 6.3.0 (021c9c19e8)
> >>
> >> Note that you can test it out via:
> >>
> >> cordova platform add https://na01.safelinks.
> protection.outlook.com/?url=https%3A%2F%2Fgithub.com%
> 2Fapache%2Fcordova-android%236.3.0=02%7C01%7C%
> 7C3b81ab94c1ca42f4e82608d505d0c8b1%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636421316685318137=BAJZVx81K0APAfoMxu7okJTuL2wcim
> Ro53kQD7S0slA%3D=0
> >>
> >> Upon a successful vote I will upload the archive to dist/, publish it
> >> to npm, and post the blog post.
> >>
> >> Voting guidelines:
> >> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgithub.com%2Fapache%2Fcordova-coho%2Fblob%2Fmaster%2Fdocs%
> 2Frelease-voting.md=02%7C01%7C%7C3b81ab94c1ca42f4e82608d505d0c8b1%
> 7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636421316685318137=
> ErZ7Y1v1sm9cPHAabw7HiToLbDrk3RDAXcNp06pzNK8%3D=0
> >>
> >> 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
> >> * Ran mobilespec on emulator and Google Pixel device
> >> * Ran Unit Tests from IDE
> >> * Ensured continuous build was green when repo was tagged
> >>
>

[Vote] 6.3.0 Android Release

[Joe Bowser]

Please review and vote on this 6.3.0 Android Release
by replying to this email (and keep discussion on the DISCUSS thread)

Release issue: https://issues.apache.org/jira/browse/CB-

The archive has been published to
dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-

The package was published from its corresponding git tag:
cordova-android: 6.3.0 (021c9c19e8)

Note that you can test it out via:

cordova platform add https://github.com/apache/cordova-android#6.3.0

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
* Ran mobilespec on emulator and Google Pixel device
* Ran Unit Tests from IDE
* Ensured continuous build was green when repo was tagged

Re: [Discuss] Cordova-Android 6.3.0 Release

[Joe Bowser]

OK, we should start the vote on Monday so that we don't leave a vote over
the weekend that people miss.  Everyone cool with that?

On Tue, Sep 5, 2017 at 4:48 PM, Simon MacDonald <simon.macdon...@gmail.com>
wrote:

> As soon as we release cordova-plugin-compat because we've added all those
> classes into cordova-android propper.
>
> Simon Mac Donald
> http://simonmacdonald.com
>
> On Tue, Sep 5, 2017 at 7:46 PM, Simon MacDonald <simon.macdon...@gmail.com
> >
> wrote:
>
> > Let's do it
> >
> > Simon Mac Donald
> > http://simonmacdonald.com
> >
> > On Tue, Sep 5, 2017 at 2:01 PM, Steven Gill <stevengil...@gmail.com>
> > wrote:
> >
> >> Lets do it. I'll update cordova-common in android now
> >>
> >> On Tue, Sep 5, 2017 at 10:58 AM, Joe Bowser <bows...@gmail.com> wrote:
> >>
> >> > Hey
> >> >
> >> > I'm back from PTO and while I was out, Android Oreo got released.  I
> >> bumped
> >> > the target SDK in the repo before I left for PTO, and I'm wondering
> how
> >> > people feel about doing a 6.3.0 release to support Oreo now that it's
> a
> >> > real thing?
> >> >
> >> > Thoughts?
> >> >
> >> > Joe
> >> >
> >>
> >
> >
>

Re: [VOTE] Plugins Release (attempt 2)

[Joe Bowser]

I vote +1

* Verified Archives
* Tested MobileSpec and made sure that Camera actually got installed
* Tested against master of cordova-android (cordova-android >= 6.3.0)

On Wed, Sep 20, 2017 at 11:25 AM, Simon MacDonald  wrote:

> I vote + 1
>
> Passed
> * Checked for deprecation notices for plugin-device-motion & orientation
> * Tested that cordova-plugin-console is not added for ios when cordova-ios
> >= 4.5.0
> * Tested that cordova-plugin-compat is not added for android when
> cordova-android >= 6.3.0
> * Added cordova-plugin-camera to a project with cordova-android 6.3.0 which
> depends on cordova-plugin-compat (from github master) and the build passes.
>
>
> Simon Mac Donald
> http://simonmacdonald.com
>
> On Wed, Sep 20, 2017 at 1:57 PM, Steven Gill 
> wrote:
>
> > Please review and vote on the release of this plugins release
> > by replying to this email (and keep discussion on the DISCUSS thread)
> >
> > Release issue: https://issues.apache.org/jira/browse/CB-13294
> >
> > The plugins have been published to
> > dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-13294/
> >
> > The packages were published from their corresponding git tags:
> > cordova-plugin-console: 1.1.0 (ef9bd9ceb4)
> > cordova-plugin-compat: 1.2.0 (be2a46be8d)
> > cordova-plugin-device-motion: 2.0.0 (1236b957af)
> > cordova-plugin-device-orientation: 2.0.0 (d6b3322fcb)
> >
> > Upon a successful vote I will upload the archives to dist/, upload
> > them to npm, and post the corresponding blog post.
> >
> > Voting guidelines:
> > https://github.com/apache/cordova-coho/blob/master/docs/
> release-voting.md
> > How to vote on a plugins release at
> > https://github.com/apache/cordova-coho/blob/master/docs/
> > plugins-release-process.md#voting
> >
> > 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 repos were tagged
> >
>

Re: [VOTE] Plugins Release

[Joe Bowser]

I vote +1

* Tested cordova-plugin-compat installation to make sure it doesn't install
on cordova-android master
* Ran mobilespec locally
* Verified signatures


On Mon, Sep 18, 2017 at 2:08 PM, Steven Gill  wrote:

> Please review and vote on the release of this plugins release
> by replying to this email (and keep discussion on the DISCUSS thread)
>
> Release issue: https://issues.apache.org/jira/browse/CB-13294
>
> The plugins have been published to
> dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-13294/
>
> The packages were published from their corresponding git tags:
> cordova-plugin-console: 2.0.0 (f0e113bdf4)
> cordova-plugin-compat: 2.0.0 (0df201c24d)
> cordova-plugin-device-motion: 2.0.0 (1236b957af)
> cordova-plugin-device-orientation: 2.0.0 (d6b3322fcb)
>
> Upon a successful vote I will upload the archives to dist/, upload
> them to npm, and post the corresponding blog post.
>
> Voting guidelines:
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
> How to vote on a plugins release at
> https://github.com/apache/cordova-coho/blob/master/docs/plug
> ins-release-process.md#voting
>
> 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 repos were tagged
>

Re: [DISCUSS] Cordova iOS 4.5.1 release

[Joe Bowser]

Is the iOS release blocked by the plugin release that is currently blocking
Android?

On Fri, Sep 15, 2017 at 4:54 PM, Mike Hartington 
wrote:

> Regarding the Viewport and iPhoneX notch, I sent this earlier today.
>
> https://github.com/apache/cordova-plugin-statusbar/pull/85 <
> https://github.com/apache/cordova-plugin-statusbar/pull/85>
>
>
> > On Sep 15, 2017, at 7:36 PM, Shazron  wrote:
> >
> > We need a 4.5.1 release soon to address iOS 11 issues.
> >
> > Here’s the things that are pending or have been fixed:
> >
> > - cordova-ios@4.5.0 has been released which fixes a bunch of things.
> Now of
> > course, we need to have a cordova-ios@4.5.1 release because of the other
> > points below…
> >
> > - ios-sim is broken, it doesn’t list the new 2017 iPhones. Apple released
> > Xcode 9 with a buggy listing of devices using `xcrun simctl` (i.e.
> listing
> > iPhone 8 as iPhone2017-A for example) so we can’t list them properly. I
> > have fixed this with a workaround:
> > https://github.com/phonegap/ios-sim/issues/218 and
> > https://github.com/phonegap/ios-sim/issues/219 - This new ios-sim when
> > released needs to go in a new cordova-ios release asap
> >
> > - simctl is broken, it doesn’t launch the Simulator (so `cordova emulate
> > ios` is affected). I have filed issues:
> > https://github.com/phonegap/ios-sim/issues/209 and
> > https://github.com/phonegap/simctl/issues/14 . Of course I will have to
> > work on those, and no surprise Apple changed things again… This will go
> in
> > the new ios-sim which in turn will go in the new cordova-ios
> >
> > - Viewport and iPhone X notch issues – with the help of the community.
> Need
> > to be addressed properly (blog post only?). Summarized by Darryl Pogue:
> >- status bar plugin -- Has a PR to use the safeArea height instead of
> > 20px
> >- iPhone X letterboxing -- Requires the use of LaunchStoryboards, not
> > really a "bug"
> >- viewport-fit stuff -- Up to the HTML author, not really a "bug", and
> > a few blogs posts about it
> >
> > - ios-deploy couldn’t compile under Xcode 9. Apple either prevents or
> had a
> > bug where it couldn’t link to Private Frameworks. Workaround added:
> > https://github.com/phonegap/ios-deploy/issues/308 . This should have
> been
> > in 4.5.0 already
>
>

[Discuss] Cordova-Android 6.3.0 Release

[Joe Bowser]

Hey

I'm back from PTO and while I was out, Android Oreo got released.  I bumped
the target SDK in the repo before I left for PTO, and I'm wondering how
people feel about doing a 6.3.0 release to support Oreo now that it's a
real thing?

Thoughts?

Joe

Re: I'm baaaaaack!

[Joe Bowser]

Welcome Back!

On Aug 22, 2017 11:55 AM, "julio cesar sanchez" 
wrote:

> Welcome back!
>
> El martes, 22 de agosto de 2017, Shazron  escribió:
>
> > Welcome back John!
> > Cordova support in Mobile Center? ;)
> >
> > On Tue, Aug 22, 2017 at 11:37 AM, John M. Wargo  > > wrote:
> >
> > > Greetings Cordova Dev Team!
> > >
> > > Its been a while, so I thought I'd pop on the list and re-introduce
> > myself.
> > >
> > > Hello, my name is John M. Wargo and I've been a Cordova developer since
> > > PhoneGap version 2 (more or less). I was a contributor for many years
> and
> > > wrote 4 books on Apache Cordova/PhoneGap, but dropped off the map about
> > two
> > > years due to a job change. I recently joined Microsoft as a Program
> > Manager
> > > working on our Mobile Center product (working for Ryan J. Salva, and
> > > working with Parashuram N - whom I think you all know). In my new
> > position,
> > > I'm not sure how much I'll be working directly with the project team,
> > but I
> > > will do what I can.
> > >
> > > I will be attending PhoneGap day in NY next month (I'll actually be
> > > Microsoft's onsite host for the event), and joining in on the dev
> > > conversation whenever I can.  Any get togethers planned for NY
> > > before/during/after the conference?  Please let me know if you need
> > > anything in or around the event.
> > >
> > > John M. Wargo
> > > Web: www.johnwargo.com 
> > > Twitter: @johnwargo 
> > >
> >
>

Re: git commits being sent to dev

[Joe Bowser]

I'm already filtering all that stuff since I'm already getting it.  In
fact, this is why I didn't see the Github invite.

But yeah, we should not have the commit e-mails go to the dev mailing list,
since it'll just spam everyone.  It'd be good if more people would use the
list to talk about proposals, or at least link to the proposal on GitHub,
since it's not the Apache way to do stuff outside of the mailing list.

(Yeah, I'm being serious about the mailing list and the Apache way.  We
should use the dev list for discussion more.)

On Tue, Aug 8, 2017 at 10:39 AM, Steven Gill  wrote:

> Hey!
>
> How do people feel about these git commit emails being sent to dev mailing
> list. This is only happening to repos that have fully switched over to
> github (gitbox setup).
>
> Personally, I am already watching the repos so I get the emails. I don't
> need the emails to come to dev. I think it would be better people just
> click watch on repos they want emails from, setup mail filters and go from
> there. No need for commit emails to be sent to dev.
>
> I could just as easily update my mail filters to move the git emails being
> sent to dev into a different directory.
>
> Thoughts?
>

Re: [DISCUSS] Accepting new apps into the App Showcase

[Joe Bowser]

+1 to no longer supporting the Apps section.  Downstream projects get more
benefit from this than we do, IMO.

On Tue, Jul 25, 2017 at 10:36 AM, Filip Maj  wrote:

> I'm of the opinion that we, the cordova devs are already sinking under
> the amount of incoming PRs and TODOs just with maintaining the
> tooling, platforms, plugins, and docs.
>
> I think it would be better to turf it and let downstream projects do
> that stuff if they wish. I think PhoneGap has one, so does ionic.
>
> On Tue, Jul 25, 2017 at 9:58 AM, Kerri Shotts 
> wrote:
> > If we’re going to have an apps section on the website, it would be good
> to keep it updated. For example, the ReactEurope app goes to a 404 page.
> Buildr navigates to an iTunes page that is not available in the US region,
> so doesn’t tell me anything (would be better to link to a website instead).
> >
> > Personally, it might be better just to drop the section entirely, since
> it will require maintenance, would end up with some subjective criteria
> (leading to “why them and not us?”), and would need to be rotated as new
> apps are added to prevent a huge list of apps on the front page. I like the
> idea, but maybe it would be better to have a Cordova App gallery (akin to
> Plugin search, cocoapods, etc.)… but that could easily be done by the
> community, since we’re tight on resources as it is.
> >
> > That said, if we’re going to accept apps, we need some (reasonable)
> criteria for acceptance, along with the proviso that we won’t necessarily
> always feature the app (since we don’t want to end up featuring 1000 apps
> on the front page).
> >
> > Some starting criteria:
> >
> > * Should currently be available for sale/download on the appropriate app
> stores.
> > * The product needs to have a website where we can link (redirecting
> into iTunes is not ideal).
> > * The product should fit with Cordova’s CoC, since it’s being featured
> on the front page.
> > * The app itself should:
> > * be visually appealing and well designed (this is subjective, but
> no getting around that…)
> > * actually work (this would require someone downloading & testing
> it. Paid apps would need to supply a review copy for free.)
> > * be performant (no jank, quick response to user input, etc.)
> > * be in production (not just a demo app)
> > * be more than just wrapping a remote website
> > * Plusses for (but not required):
> > * Available source code (so others can learn from the app)
> > * Multiple platform support
> > * Free or usable trial version so that users can get a good feel for
> a performant Cordova app
> >
> > Those are just off the top of my head, so take them as you will. :-)
> >
> > ~ Kerri
> >
> >> On Jul 24, 2017, at 19:24, Shazron  wrote:
> >>
> >> https://cordova.apache.org
> >>
> >> Are we still accepting apps? How do we select?
> >> Right now there are 12. This relates to the Xmind request to dev@
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Proof-of-Concept: Studio Project Structure Cleanup

[Joe Bowser]

Hey

After the eslint merge, I redid the PR, so here's the new branch for the
StudioProjectCleanup.  Can more people look at it, I'll be working on some
refactors on here, but AFAIK, there's no good reason to not merge this into
master and get ready to start ramping up Cordova-Android 7.0.0

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

Any thoughts?

Joe

On Fri, Jun 9, 2017 at 3:27 PM, Joe Bowser <bows...@gmail.com> wrote:

> Hey
>
> I know that I've talked about this before, but I think that with the
> adoption of Kolton as a supported Android development language and with
> recent Gradle changes on the CLI, it's time to migrate our generated
> Android project structure to something a bit more modern so that we can
> support modern Android development.  That being said, we need to make sure
> that existing projects can just keep the same code that has worked for them
> working, so here's the branch that I've been working on.  All the plugin
> installation works, but I need help with the upgrade scripts working for
> both structures:
>
> https://github.com/infil00p/cordova-android/tree/StudioProjectCleanup
>
> Here's the PR: (It's HUGE)
> https://github.com/apache/cordova-android/pull/384
>
> The downside of all of this is that we've now forever adopted
> project.properties to keep track of all the Android libraries that the
> plugins use, but that's the price we have to pay currently if we want to be
> able to have the plugins install gradle dependencies, otherwise managing
> the dependencies would be a nightmare.  (You'd think Gradle could do this
> on its own, but nope)
>
> So, if anyone hates Java and wants to write Kolton, or if people just want
> their Cordova-Android projects to look like a regular Android project, this
> PR may be right for you.  Feel free to check it out.  This would be a
> Cordova-Android 7.0 change.
>
> BTW: This is not directly related to Android O, but it may help.
>
> Joe
>

Re: Cordova-Android 7.0.0 Review request

[Joe Bowser]

BUMP!  Let's see if we can get some traction behind these:

Here's the latest StudioProjectCompat PR:
https://github.com/apache/cordova-android/pull/389

On Thu, Jun 22, 2017 at 10:57 AM, Joe Bowser <bows...@gmail.com> wrote:

> BTW: I also want to pull this in:
>
> https://github.com/apache/cordova-android/pull/385/files
>
>
>
> On Thu, Jun 22, 2017 at 10:38 AM, Joe Bowser <bows...@gmail.com> wrote:
>
>> Hey
>>
>> So, there's currently a two outstanding PRs that I want to throw into
>> Cordova-Android 7.0.0:
>>
>> https://github.com/apache/cordova-android/pull/384
>> https://github.com/apache/cordova-android/pull/352
>>
>> The thing is that I want some people to actually review these changes
>> before I add them.  I'm also going to be sending another PR soon putting
>> the Whitelist, Splashscreen and Compat plugins back into Cordova Android
>> since it never made sense for them to be plugins in the first place, and it
>> was ideologically driven more than anything practical.
>>
>> Since we have a major release on the horizon, I am going to need the
>> community's help to review this and get this release out.  We've been
>> trying to do a major effort to not patch bomb the crap out of Cordova by
>> pushing back on features, but given how far Cordova-Android has drifted
>> from mainstream Android development, I think it's time we update it and
>> move forward with Cordova-Android 7.0.0.  That said, before we can land
>> these patches, and get a discuss thread, I really need some review.
>>
>> So, if you're running a project that is legacy, or you have tooling that
>> relies on Cordova not changing, or your company is based on this project,
>> please review these patches and participate in the process.  We really need
>> to move forward, and I would prefer to not just throw crap over the fence
>> this time around.
>>
>> Thanks
>>
>> Joe
>>
>>
>>
>

Cordova-Android 7.0: Upgrading Java Requirement to 7.0

[Joe Bowser]

Hey

I think we should accept this PR to attract newer developers.  Sure, we
could adopt Java 8, but I think being stuck with Java 6 may be limiting
contributions.  Does anyone have any thoughts on this?

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

Re: Cordova-Android 7.0.0 Review request

[Joe Bowser]

BTW: I also want to pull this in:

https://github.com/apache/cordova-android/pull/385/files



On Thu, Jun 22, 2017 at 10:38 AM, Joe Bowser <bows...@gmail.com> wrote:

> Hey
>
> So, there's currently a two outstanding PRs that I want to throw into
> Cordova-Android 7.0.0:
>
> https://github.com/apache/cordova-android/pull/384
> https://github.com/apache/cordova-android/pull/352
>
> The thing is that I want some people to actually review these changes
> before I add them.  I'm also going to be sending another PR soon putting
> the Whitelist, Splashscreen and Compat plugins back into Cordova Android
> since it never made sense for them to be plugins in the first place, and it
> was ideologically driven more than anything practical.
>
> Since we have a major release on the horizon, I am going to need the
> community's help to review this and get this release out.  We've been
> trying to do a major effort to not patch bomb the crap out of Cordova by
> pushing back on features, but given how far Cordova-Android has drifted
> from mainstream Android development, I think it's time we update it and
> move forward with Cordova-Android 7.0.0.  That said, before we can land
> these patches, and get a discuss thread, I really need some review.
>
> So, if you're running a project that is legacy, or you have tooling that
> relies on Cordova not changing, or your company is based on this project,
> please review these patches and participate in the process.  We really need
> to move forward, and I would prefer to not just throw crap over the fence
> this time around.
>
> Thanks
>
> Joe
>
>
>

Cordova-Android 7.0.0 Review request

[Joe Bowser]

Hey

So, there's currently a two outstanding PRs that I want to throw into
Cordova-Android 7.0.0:

https://github.com/apache/cordova-android/pull/384
https://github.com/apache/cordova-android/pull/352

The thing is that I want some people to actually review these changes
before I add them.  I'm also going to be sending another PR soon putting
the Whitelist, Splashscreen and Compat plugins back into Cordova Android
since it never made sense for them to be plugins in the first place, and it
was ideologically driven more than anything practical.

Since we have a major release on the horizon, I am going to need the
community's help to review this and get this release out.  We've been
trying to do a major effort to not patch bomb the crap out of Cordova by
pushing back on features, but given how far Cordova-Android has drifted
from mainstream Android development, I think it's time we update it and
move forward with Cordova-Android 7.0.0.  That said, before we can land
these patches, and get a discuss thread, I really need some review.

So, if you're running a project that is legacy, or you have tooling that
relies on Cordova not changing, or your company is based on this project,
please review these patches and participate in the process.  We really need
to move forward, and I would prefer to not just throw crap over the fence
this time around.

Thanks

Joe

Re: [Android] Let's drop support for Jellybean

[Joe Bowser]

The problem is that Kitkat is still 18.1% of the current devices out there,
which includes all the failed experiment devices that Google had released.
That would be dropping a lot of things by the wayside.

On Mon, Jun 12, 2017 at 12:48 PM, Simon MacDonald <simon.macdon...@gmail.com
> wrote:

> +1 from me as well.
>
> If we can move to Android 5.0 (API 21) and later that would be a huge win
> as all of those devices can use the Android System WebView
> <https://play.google.com/store/apps/details?id=com.
> google.android.webview=en>
> which
> gives us a more consistent target.
>
> Simon Mac Donald
> http://simonmacdonald.com
>
> On Mon, Jun 12, 2017 at 2:35 PM, Kerri Shotts <kerrisho...@gmail.com>
> wrote:
>
> > +1
> >
> >
> > ~ Kerri
> >
> > > On Jun 12, 2017, at 13:22, Trevor Brindle <tabrin...@gmail.com> wrote:
> > >
> > > +1 makes sense to me. Ensuring testability and not making heroic
> measures
> > > to continue support an old OS is a good reason to me.
> > >
> > > TrevorBrindle
> > > Lead Hybrid Mobile Engineer
> > > SHOP•COM powered by marketamerica
> > > C: (407) 450-8700
> > >
> > > On Mon, Jun 12, 2017 at 1:23 PM, Shazron <shaz...@gmail.com> wrote:
> > >
> > >> +1
> > >>
> > >> On Mon, Jun 12, 2017 at 8:38 AM, julio cesar sanchez <
> > >> jcesarmob...@gmail.com
> > >>> wrote:
> > >>
> > >>> Currently, Jellybean is 8.8%, so it's bellow the 10%. We can drop it.
> > >>>
> > >>>
> > >>> 2017-06-12 17:22 GMT+02:00 Filip Maj <maj@gmail.com>:
> > >>>
> > >>>> Reviving this thread! Sorry for the late reply.
> > >>>>
> > >>>> Regarding Trevor's question:
> > >>>>> Just for consideration however, what do we actually gain by
> dropping
> > >>>>> official support? Are there compat libraries or tests we can drop
> > >> after
> > >>>>> this?
> > >>>>
> > >>>> From a testing/CI perspective, it becomes much more tenable to keep
> up
> > >>>> with pull requests and ensure changes are validated on the platforms
> > >>>> we support. We currently leverage Sauce Labs to run tests on
> emulators
> > >>>> on Android, and Sauce dropped support for all Android versions up to
> > >>>> and including 4.3 [1]. So, from a selfish perspective, as a cordova
> > >>>> dev, dropping 4.3 and below support makes _my_ life easier as I
> don't
> > >>>> have to manually test on earlier versions of Android.
> > >>>>
> > >>>> Not sure if there are other, less-selfish reasons? Ping Simon + Joe.
> > >>>>
> > >>>> Also, instead of letting this thread die a quiet death, may I
> suggest
> > >>>> that whatever decision is made here, we file as issues and chalk up
> > >>>> for the next cordova-android major release?
> > >>>>
> > >>>> [1] https://wiki.saucelabs.com/display/DOCS/2017/03/30/EOL+
> > >>>> for+Android+4.0%2C+4.1%2C+4.2%2C+and+4.3+Automated+Mobile+
> App+Testing
> > >>>>
> > >>>> On Sun, Feb 26, 2017 at 4:36 PM, Trevor Brindle <
> tabrin...@gmail.com>
> > >>>> wrote:
> > >>>>> I don't think it is unreasonable to drop support for an OS that had
> > >> its
> > >>>>> first release in July of 2012 (4.1 is almost 5 years old),
> especially
> > >>>>> considering the Cordova support policy for iOS.
> > >>>>>
> > >>>>> Realistically, I think it's hard to justify support for before 4.4.
> > >>> Less
> > >>>>> than 10% of our customers are on 4.4 or earlier as a whole, and
> less
> > >>> than
> > >>>>> 10% of them actually use our apps regularly.
> > >>>>>
> > >>>>> Just for consideration however, what do we actually gain by
> dropping
> > >>>>> official support? Are there compat libraries or tests we can drop
> > >> after
> > >>>>> this?
> > >>>>>
> > >>>>> On Sun, Feb 26, 2017 at 12:10 PM Simon MacDonald <
> > >>>> simon.macdon...@gmail.com>
> > >>>>> wrote:
>

Proof-of-Concept: Studio Project Structure Cleanup

[Joe Bowser]

Hey

I know that I've talked about this before, but I think that with the
adoption of Kolton as a supported Android development language and with
recent Gradle changes on the CLI, it's time to migrate our generated
Android project structure to something a bit more modern so that we can
support modern Android development.  That being said, we need to make sure
that existing projects can just keep the same code that has worked for them
working, so here's the branch that I've been working on.  All the plugin
installation works, but I need help with the upgrade scripts working for
both structures:

https://github.com/infil00p/cordova-android/tree/StudioProjectCleanup

Here's the PR: (It's HUGE)
https://github.com/apache/cordova-android/pull/384

The downside of all of this is that we've now forever adopted
project.properties to keep track of all the Android libraries that the
plugins use, but that's the price we have to pay currently if we want to be
able to have the plugins install gradle dependencies, otherwise managing
the dependencies would be a nightmare.  (You'd think Gradle could do this
on its own, but nope)

So, if anyone hates Java and wants to write Kolton, or if people just want
their Cordova-Android projects to look like a regular Android project, this
PR may be right for you.  Feel free to check it out.  This would be a
Cordova-Android 7.0 change.

BTW: This is not directly related to Android O, but it may help.

Joe

Re: [VOTE] 6.2.3 Android release

[Joe Bowser]

I vote +1

* Ran mobile spec testing the new emulator-handling code, via `cordova
run --emulator`, w/ latest plugin code.
* Ensured can use bin/create to create project
* Ran empty project created by bin/create against emulator
* Created a project with the CLI and ran it on the emulator

On Tue, May 2, 2017 at 5:02 PM, Filip Maj  wrote:

> Please review and vote on this 6.2.3 Android Release by replying to
> this email (and keep discussion on the DISCUSS thread - am
> piggy-backing on the 6.2.2 release DISCUSS thread)
>
> Release issue: https://issues.apache.org/jira/browse/CB-12746
>
> The archive has been published to
> dist/dev: https://dist.apache.org/repos/dist/dev/cordova/CB-12746
>
> The package was published from its corresponding git tag:
> cordova-android: 6.2.3 (c0df73c3)
>
> Note that you can test it out via:
>
> cordova platform add https://github.com/apache/cordova-android#6.2.3
>
> Upon a successful vote I will upload the archive to dist/, publish it
> to npm, and post the blog post.
>
> I have also sent a PR for the blog post related to this release -
> reviews requested, please take a look:
> https://github.com/apache/cordova-docs/pull/702
>
> 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 mobile spec on a real device, w/ latest plugin code.
> * Ran mobile spec testing the new emulator-handling code, via `cordova
> run --emulator`, w/ latest plugin code.
> * Ensured can create a new project using cordova-cli, and run on both
> device and emulator
> * Ensured can use the bin/create script.
> * Double-checked reported versions via `cordova/version` script.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Proof of Concept: Android Studio Project Structure

[Joe Bowser]

No.  If you're a CLI user, you shouldn't notice the change once everything
is complete.  This change
is for people who have to do some Android development to integrate some new
feature or write a custom
plugin or something.

Of course, we already have other problems with people who don't have
Android Studio setup trying to build Cordova, but that's not what this
proposal is about.  This is about making sure Google doesn't break us
further.

On Mon, Apr 24, 2017 at 9:50 AM, Filip Maj <maj@gmail.com> wrote:

> Dropping ANT support now seems like a good idea.
>
> This overall sounds good to me. One question I have is how would this
> affect users that have only the command-line tools installed, and not
> a full Android studio setup? Does this approach preclude those users
> from leveraging Cordova? I'm not sure that's a showstopper to me, but
> I would like to clarify that.
>
> On Mon, Apr 24, 2017 at 9:30 AM, Joe Bowser <bows...@gmail.com> wrote:
> > Hey
> >
> > Since we've been running into numerous issues with Google updating their
> > tools already, I think it's time that we update the new project structure
> > to work with Android Studio more easily so that we can integrate JUnit
> > tests for plugins, Library Projects, Gradle dependencies and allow for
> > people to work with Android Studio and Android tools more easily on
> Cordova
> > projects.
> >
> > Right now, I have a branch where I'm currently working on stuff.  I don't
> > have upgrade scripts working, nor do I have plugin installation working
> > yet, but this will auto-detect the structure and will pick the right
> > builder for the project.  You can check it out here.
> >
> > https://github.com/infil00p/cordova-android/tree/StudioProjectCleanup
> >
> > It should be noted that we kinda half-assed the ANT support and that we
> > never properly supported Ant, so I think we should officially drop Ant
> > support in the next version of Apache Cordova regardless.
> >
> > The big elephant in the room is the plugin installer and the fact that
> > plugin authors basically abandon their projects after the 1.0 release.
> > Cordova probably has the most abandonware that I've ever seen.  We're
> going
> > to have to write a LOT of mapper code just to keep the old plugins
> working
> > since people are using them regardless of their abandonware status, and
> we
> > don't have the resources to re-write every plugin everywhere and support
> > them.
> >
> > That said, we've used plugins as an excuse to not upgrade for three years
> > now, and I think the problems with this position are going to get a lot
> > worse the longer we pretend that Android Studio doesn't exist.
> >
> > Here's the TL;DR of what I propose:
> > 1. Change project structure so new Cordova-Android platform directories
> > have an Android Studio directory structure.
> > 2. Allow for existing projects to stay the same for the time being and
> for
> > a project upgrade to be hidden behind a flag
> > 3. Move plugins to work like library projects and possibly AARs down the
> > road.
> >
> > I know that I've written this e-mail before, but it would be great if we
> > could finally move forward with this change before Google breaks more
> stuff
> > with our current builds.
> >
> > Thoughts?
> >
> > Joe
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Proof of Concept: Android Studio Project Structure

[Joe Bowser]

Hey

Since we've been running into numerous issues with Google updating their
tools already, I think it's time that we update the new project structure
to work with Android Studio more easily so that we can integrate JUnit
tests for plugins, Library Projects, Gradle dependencies and allow for
people to work with Android Studio and Android tools more easily on Cordova
projects.

Right now, I have a branch where I'm currently working on stuff.  I don't
have upgrade scripts working, nor do I have plugin installation working
yet, but this will auto-detect the structure and will pick the right
builder for the project.  You can check it out here.

https://github.com/infil00p/cordova-android/tree/StudioProjectCleanup

It should be noted that we kinda half-assed the ANT support and that we
never properly supported Ant, so I think we should officially drop Ant
support in the next version of Apache Cordova regardless.

The big elephant in the room is the plugin installer and the fact that
plugin authors basically abandon their projects after the 1.0 release.
Cordova probably has the most abandonware that I've ever seen.  We're going
to have to write a LOT of mapper code just to keep the old plugins working
since people are using them regardless of their abandonware status, and we
don't have the resources to re-write every plugin everywhere and support
them.

That said, we've used plugins as an excuse to not upgrade for three years
now, and I think the problems with this position are going to get a lot
worse the longer we pretend that Android Studio doesn't exist.

Here's the TL;DR of what I propose:
1. Change project structure so new Cordova-Android platform directories
have an Android Studio directory structure.
2. Allow for existing projects to stay the same for the time being and for
a project upgrade to be hidden behind a flag
3. Move plugins to work like library projects and possibly AARs down the
road.

I know that I've written this e-mail before, but it would be great if we
could finally move forward with this change before Google breaks more stuff
with our current builds.

Thoughts?

Joe

Re: [Vote] 6.2.1 Android Release (attempt 2)

[Joe Bowser]

I vote +1

* Ran coho verify-tags
* Ran mobile-spec
* Ran BRAND NEW Native Unit Tests  (Yay!!!)
* Verified that a blank app creates correctly
* Verified that platform can successfully build and run

On Mon, Apr 3, 2017 at 1:51 AM,  wrote:

> I vote +1.
>
> * Verified archives via `coho verify-archive`
> * Verified tags manually
> * Verified that blank app creates correctly with platform
> * Verified that blank app can successfully build and run
> * Verified that platform can be updated from previous version
> * Verified compatibility with core plugins (released and master versions)
> * Verified release notes
> * Verified version
> * Verified line breaks
>
> Thanks,
> Alexander Sorokin
>
> -Original Message-
> From: Steven Gill [mailto:stevengil...@gmail.com]
> Sent: Monday, April 3, 2017 3:14 AM
> To: dev@cordova.apache.org
> Subject: [Vote] 6.2.1 Android Release (attempt 2)
>
> Please review and vote on this 6.2.1 Android Release by replying to this
> email (and keep discussion on the DISCUSS thread)
>
> Release issue: https://issues.apache.org/jira/browse/CB-12627
>
> The archive has been published to
> dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-12627
>
> The package was published from its corresponding git tag:
> cordova-android: 6.2.1 (d36cfeafa2)
>
> Note that you can test it out via:
>
> cordova platform add https://github.com/apache/cordova-android#6.2.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
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Should we force the use of the Gradle daemon?

[Joe Bowser]

After looking at this for a bit, I'm not sure exactly why we added it.  We
should allow it to be turned off, but I think we may want to keep it on for
the default just to be safe.

On Thu, Mar 30, 2017 at 8:38 AM,  wrote:

> Hey devs,
>
> TL;DR: Gradle daemon can cause problems on some environments. Why do we
> force it on?
> ---
> Recently, I tried to disable the Gradle daemon for Android builds on our CI
> (because it is unstable when running concurrent builds), but found that it
> is nearly impossible to do. To each Gradle invocation, Cordova adds an
> argument which forces the usage of the daemon[1].
> I've also found that some other users had issues with the daemon[2].
>
> At the moment, you cannot disable it for good. Even if you do "cordova
> build
> android -- --gradleArg=-Dorg.gradle.daemon=false", it would only fix
> things
> for the build command. The Gradle daemon is still invoked when adding a
> plugin.
>
> I ended up creating a monkey patch commenting this line out on our CI, but
> I
> don't think it is the best solution here.
>
> So, what I wanted to ask is: Do we really need to force it on like this?
> Can't we just rely on user's Gradle properties?
>
> [1]
> https://github.com/apache/cordova-android/blob/master/
> bin/templates/cordova/
> lib/builders/GradleBuilder.js#L57
> [2] https://forum.ionicframework.com/t/kill-the-gradle-daemon/31690
>
> Thanks,
> Alexander Sorokin
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [Vote] 6.2.0 Android Release

[Joe Bowser]

I vote +1:
* Ran coho verify-tags
* Ran mobile-spec
* Ran BRAND NEW Native Unit Tests  (Yay!!!)



On Tue, Mar 28, 2017 at 4:01 PM, Steven Gill  wrote:

> Please review and vote on this 6.2.0 Android Release
> by replying to this email (and keep discussion on the DISCUSS thread)
>
> Release issue: https://issues.apache.org/jira/browse/CB-12609
>
> The archive has been published to
> dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-12609
>
> The package was published from its corresponding git tag:
> cordova-android: 6.2.0 (4d55fdb3e5)
>
> Note that you can test it out via:
>
> cordova platform add https://github.com/apache/cordova-android#6.2.0
>
> 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
> * Ran through testing section at
> https://github.com/apache/cordova-coho/blob/master/docs/
> platforms-release-process.md#what-to-test
>

Re: [DISCUSS] Cordova-Android 6.2.0 Release

[Joe Bowser]

OK, I got everything I wanted in the release in.  It's relatively future
proof for the time being on Linux and Windows, and Alexander's last minute
fix was a good catch (although I'm not sure why an earlier check didn't
work on Windows, and that bothers me a little, but not enough to vote
against this thing).

Darryl, I'm fine with the patch being in, but I'd like people who use the
CLI on a regular basis to test it, since my main use cases these days are
standalone and Android Studio Integration, and I definitely wouldn't be as
through.

Are people generally in agreement?

On Tue, Mar 21, 2017 at 2:48 PM, Darryl Pogue <dvpdin...@gmail.com> wrote:

> I have tested locally and it works when adding the platform and
> running prepare, with the following cases.
>
> Existing src to target: works
> Existing src to target in new directory: works
> Nonexisting src to target: Error (consistent with icon/splash tags)
>
> There aren't any unit tests, but there don't appear to be any test
> cases for icons or splash screen copying either.
>
> If you think there are more cases not covered here, please let me know.
>
>
> On 21 March 2017 at 14:07, Jesse <purplecabb...@gmail.com> wrote:
> >
> > So do we need to wait for anything to get the resource-file work in?
> > How well tested is it? Do you feel confident that it will not delay the
> > overall release?
> >
> > I would really like to see a release out sooner rather than later, as
> > things are broken right now. [1] [2]
> >
> >
> >
> > [1] https://issues.apache.org/jira/browse/CB-12524
> > [2] https://issues.apache.org/jira/browse/CB-12546
> >
> >
> >
> >
> > @purplecabbage
> > risingj.com
> >
> > On Mon, Mar 20, 2017 at 12:38 PM, Filip Maj <maj@gmail.com> wrote:
> >
> > > I am all for a new release, to get compatibiltiy with the latest SDK
> > > tooling out ASAP. No objections here.
> > >
> > > On Mon, Mar 20, 2017 at 12:36 PM, Joe Bowser <bows...@gmail.com>
> wrote:
> > > > Hey
> > > >
> > > > Does anyone have any reason to delay Cordova-Android 6.2.0? I want to
> > > get a
> > > > release out to address the problems people are having with the latest
> > > > Android Tools.  There's also a multipart fix that I want to get into
> the
> > > > release if possible.
> > > >
> > > > If there's no objections, I'll start the release process either
> tomorrow
> > > or
> > > > Wednesday (when I get a desk to sit at to do this).
> > > >
> > > > Joe
> > >
> > > -
> > > 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
>
>

[DISCUSS] Cordova-Android 6.2.0 Release

[Joe Bowser]

Hey

Does anyone have any reason to delay Cordova-Android 6.2.0? I want to get a
release out to address the problems people are having with the latest
Android Tools.  There's also a multipart fix that I want to get into the
release if possible.

If there's no objections, I'll start the release process either tomorrow or
Wednesday (when I get a desk to sit at to do this).

Joe

[Android] Android 25.3.1 and the case of the missing Gradle Wrapper

[Joe Bowser]

Hey

It looks like Google updated the SDK tools and broke the entire Android
build in the process.  It looks like we're going to have to re-write the
entire GradleBuilder, and we may need to bundle our own version of the
Gradle Wrapper in the project and make sure that we keep pace with the
latest Android Gradle Wrapper.

This is a blocker, and right now we advise people to not upgrade their
Android tools until we get this resolved.  That being said, this will
probably take weeks, if not a month or more to resolve since we're going to
have to re-work one of the most complex, if not the most complex parts of
the build scripts so that it works again.

So, first of all, can we even distribute a gradle wrapper in a project, or
is there some legal thing preventing us?

Secondly, does anyone want to help re-write this thing? Honestly, our build
scripts are some special unique hell of Javascript and Gradle that I can't
see anyone wanting to volunteer to do, but if people step up, I'd be very
greatful.

Finally, we don't have a ton of time to do this.  I eventually got the
broken SDK by switching to the Canary channel on Android Studio, but people
accidentally got this when it was pushed to stable.

Any thoughts?  Anyone want to help with this?

Joe

[Android] Let's drop support for Jellybean

[Joe Bowser]

Hey

Even though everything appears to be working on Jellybean, I know a lot of
people have been wanting to throw it to the wayside.  Normally, for us to
drop support for a platform, we have to wait unitl it goes below 10%, but
since Jellybean consists of three different API versions, and since two of
those are below the 5% mark, I'm tempted to just toss it by the wayside and
set the minimum supported version of Android to 4.4.x, or API level 19.

How do people feel about that.  I know in the past, people were super
passionate about supporting everything, but given that my Android 4.1
device is an old Nitobi device obtained before we even became Adobe, and it
took five tries to get it to cooperate with adb, I'm really starting to
think it's time we dropped Jellybean.

Thoughts?

Joe

Update on Android Unit Test Re-Write

[Joe Bowser]

Hey

So, this would have happened sooner, but I have the new format with most of
the tests migrated.  Due to permission issues, I deleted the Cordova
Resource API integration test, but if someone wants to figure out how to
get that working, feel free.

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

The big change is the new Unit Test for the bridge.  The bridge currently
has almost no documentation, and since it's the core of the whole thing, we
should probably add more unit tests before we do any more changes. I could
go into more detail about this, but it would be mostly table-flipping and
me saying things that aren't super helpful right now.

The tests are in no way complete, but they're now more consistent with the
modern Android Unit Testing framework, so hopefully people will now write
tests before adding features, or fixing bugs so that we can be sure that we
don't have regressions.  Also, it's so I can say "if there's no test for
it, it's not a regression".

Please look over this PR, I plan to have this merged in on Friday if
there's no comments.

Joe

Cordova Android Test Re-Write

[Joe Bowser]

Hey

So, after the last release when we switched bridge modes, we ran into some
issues related to the new bridge not behaving exactly like the old bridge.
This isn't a huge deal, since the old bridge never went away, and you can
manually set the bridge, but it would have been good to actually have some
unit tests related to this.

Basically, we're at the point where I'm not going to accept any new PRs on
Cordova-Android outside of gradle PRs until we get some solid tests in
place.  The old unit tests were refactored back in 2015, and unfortunately
the person who did it removed a lot of tests that were required and wrote
other tests that no longer work with the current permission system in
Android.  Combined with the fact that we have to update the tests to use
the new instrumentation, since the old instrumentation could be deprecated
any day now, we need to do a rewrite.

At any rate, the plan is as follows:

1. The unit tests are being written on my branch currently, and once I feel
we have feature parity with what currently exists, minus the ones that I
don't think make any sense, I'll be pushing these up to master.

https://github.com/infil00p/cordova-android/tree/unit_tests

2. Once these are done, I will be expecting any non-trivial change to
Cordova-Android to have a corresponding Instrumentation Test involving both
HTML/CSS/JS and jUnit tests.  If I see a PR without a jUnit test, added to
the new test project, it will not be accepted.

3. Once this is done, I do plan on moving plugins to be library projects,
and these library projects will also have jUnit tests.  This means that we
can hopefully avoid PRs that break the EXIF data and other major problems
that people have been having with these plugins.

Questions, comments about this plan? Want to help? Let me know?

Joe

CVE-2017-3160: Gradle Distribution URL used by Cordova-Android does not use https by default

[Joe Bowser]

===
CVE-2017-3160: Gradle Distribution URL used by Cordova-Android does not use
https by default

Severity: High

Vendor: The Apache Software Foundation

Versions Affected: Cordova Android (6.1.1 and below)

Description: After the Android platform is added to Cordova the first time,
or after a project is created using the build scripts, the scripts will
fetch Gradle on the first build. However, since the default URI is not
using https, it is vulnerable to a MiTM and the Gradle executable is not
safe. The severity of this issue is high due to the fact that the build
scripts immediately start a build after Gradle has been fetched.

Upgrade path: Developers who are concerned about this issue should install
version 6.1.2 or higher of Cordova-Android.

Mitigation Steps: If developers are unable to install the latest version,
this vulnerability can easily be mitigated by setting the
CORDOVA_ANDROID_GRADLE_DISTRIBUTION_URL environment variable to
https://services.gradle.org/distributions/gradle-2.14.1-all.zip

Credit: Alon Galili

Re: CB-11602: (android) Adds onRestart event support

[Joe Bowser]

OK, time to address the elephant in the room:

Why is the Splashscreen still a plugin?  It was only made a plugin because
someone wanted to be a purist about plugins, and there's actually no good
reason for it to not just be built into Cordova.  I used to think
Splashscreens were dumb and were used to cover up bad loading times, but
there's a good business case for them since people expect them.

Also, related, Splashscreen on Android needs to be rebuilt anyway.  There's
numerous bugs with it, and I think adding it back into the platforms might
actually delete code and simplify things.

I know that we said these exact things before at meetings and wrote them in
minutes that we posted here, but I think now is probably good time to bring
this up.

The only reason I don't want to throw this back into Android is because I
don't want crap ton of PRs in Cordova-Android just all about Splashscreen.
That said, at least we can get those unit tested and actually make sure
that 3 second delays are actually 3 seconds and not some random value, and
other things like that.


On Tue, Jan 24, 2017 at 10:47 PM, Jesse  wrote:

> I would like to see us move towards making this platform level
> functionality,  The requirements of this API happen mostly outside of the
> scope of a plugin's lifetime.
>
> If we could get to an api that was just, images with the right names are
> presented when the OS decides to do it, the way all native platforms work,
> I think we would be better off.
>
>
> @purplecabbage
> risingj.com
>
> On Fri, Jan 20, 2017 at 3:28 AM,  wrote:
>
> > Hello,
> >
> > There's a related issue marked as WontFix [1][2] but as far as I
> > understand it does not apply to the SplashScreen plugin as it is
> > initialized on startup (via ).
> > So the question is - should we add onRestart as it is not fundamentally
> > different from onStart, which is supported?
> > Or is there a better/more correct way to do it?
> >
> > [1]: https://issues.apache.org/jira/browse/CB-9620
> > [2]: https://issues.apache.org/jira/browse/CB-9621
> >
> > Please let me know if you have any questions or considerations.
> >
> > Best regards,
> > Sergey Shakhnazarov,
> > Akvelon developer.
> >
> > -Original Message-
> > From: Sergey Shakhnazarov [mailto:dase...@apache.org]
> > Sent: Thursday, January 12, 2017 12:10
> > To: dev 
> > Subject: CB-11602: (android) Adds onRestart event support
> >
> > Hi guys,
> >
> > I've investigated the CB-11602 Splashscreen plugin receives onPause and
> > hides [1] and realized that the splashscreen plugin currently doesn't
> > handle onStop->onRestart [2] events properly.
> > The reason is that we don't have the onRestart event in cordova-android
> so
> > I propose to add it [3] and update the splash screen plugin code
> > accordingly to handle this pause-resume events correctly [4] (i.e.
> > save/restore the splashscreen state on app switch/device lock).
> > Please take a look.
> >
> > [1]: https://na01.safelinks.protection.outlook.com/?url=https%3A%
> > 2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCB-11602=02%
> > 7C01%7Cv-seshak%40microsoft.com%7Cb58575c22fb04ad3c29308d4
> > 3acabe0f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636198
> > 089826262946=ic0pYXcxfToH7eHWkPUktKDgm0aYMhHgfxqhJ8ECS
> > sU%3D=0
> > [2]:
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%
> > 2F%2Fdeveloper.android.com%2Freference%2Fandroid%2Fapp%
> > 2FActivity.html%23onRestart=02%7C01%7Cv-seshak%
> > 40microsoft.com%7Cb58575c22fb04ad3c29308d43acabe0f%7C72f988b
> > f86f141af91ab2d7cd011db47%7C1%7C0%7C636198089826262946=Ido%
> > 2FCxLiFO9fdJxCTb1HvIt9dBo%2BMtIjwUqo6%2FDyPaw%3D=0()
> > [3]: https://na01.safelinks.protection.outlook.com/?url=https%3A%
> > 2F%2Fgithub.com%2Fapache%2Fcordova-android%2Fpull%
> > 2F353%2Ffiles=02%7C01%7Cv-seshak%40microsoft.com%7Cb
> > 58575c22fb04ad3c29308d43acabe0f%7C72f988bf86f141af91ab2d7cd0
> > 11db47%7C1%7C0%7C636198089826272954=mMHBhAcWSuBXgWOVFS
> > TyX8tV8cikEKfAO4hX95A7Zcs%3D=0
> > [4]: https://na01.safelinks.protection.outlook.com/?url=https%3A%
> > 2F%2Fgithub.com%2Fapache%2Fcordova-plugin-splashscreen%
> > 2Fpull%2F120%2Ffiles=02%7C01%7Cv-seshak%40microsoft.
> > com%7Cb58575c22fb04ad3c29308d43acabe0f%7C72f988bf86f141af91a
> > b2d7cd011db47%7C1%7C0%7C636198089826272954=Xg5ldRRKYwl
> > UGvbCWMUOzk2HIzWStMJze0jFTzif3A8%3D=0
> >
> > Best regards,
> > Sergey Shakhnazarov,
> > Akvelon developer.
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>

Re: plugins and engines

[Joe Bowser]

OK, so we've already agreed to this? Why don't we just do this?

On Wed, Jan 4, 2017 at 10:52 PM, Vladimir Kotikov (Akvelon) <
v-vlk...@microsoft.com> wrote:

> Here is another relevant proposal and discussion:
> https://github.com/cordova/cordova-discuss/pull/30. I think we’ve agreed
> to follow this way to “pin” specific plugins’ versions to specific cordova
> versions.
>
> Here are some examples:
> 1. https://github.com/apache/cordova-plugin-inappbrowser/
> blob/master/package.json#L47-L54
> 2. https://github.com/litehelpers/Cordova-sqlite-
> storage/blob/storage-master/package.json#L13-L17
>
> -
> Best regards, Vladimir
>
>
> On 1/4/17, 19:21, "julio cesar sanchez"  wrote:
>
> I think we should start testing plugins with cordova-android 4.1.1 as
> is
> the lower required by Google to publish on Google play. If some plugin
> doesn't compile then increase the engine version to next
> cordova-android.
> In example, camera plugin doesn't compile with cordova-android 4.1.1.
>
> For cordova-ios we should require at least 3.4.1 as is the version that
> included the 64bit support, required by apple, not sure if they
> require a
> newer version for some other reason now.
>
>
> El 4 ene. 2017 2:52 p. m., "Filip Maj"  escribió:
>
> > Sounds like a good idea, but how to go about doing it? We probably
> > can't easily, for example, rule out older versions of iOS without
> > someone testing with an old Xcode version.
> >
> > On Tue, Jan 3, 2017 at 5:15 PM, Shazron  wrote:
> > > Related: https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCB-6582&
> data=02%7C01%7Cv-vlkoti%40microsoft.com%7Ce2cfd36143c74c85e24408d434bd
> b765%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
> 7C636191436803774697=Ny5sFt0LDFmoCUyQbYW1%2B%
> 2Flf38Sz2QKpfuFLqNO3aRE%3D=0
> > > (almost 3 years old...)
> > >
> > > TLDR; we should update the engine tags, with as much granularity as
> > > possible.
> > >
> > > I think we didn't do this because we don't actually know if it
> *doesn't*
> > > work on an older version (since of course we don't test the current
> > version
> > > with older platform version) and didn't want to unnecessarily
> restrict a
> > > user from installing it.
> > >
> > > We planned to pin core plugins to a cordova-lib version but we
> decided to
> > > use engine tags in plugins:
> > > https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgithub.com%2Fcordova%2Fcordova-discuss%
> 2Fblob%2Fmaster%2Fproposals%2F=02%7C01%7Cv-vlkoti%40microsoft.com%
> 7Ce2cfd36143c74c85e24408d434bdb765%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636191436803774697=2bK2SeDLFC50%2Boo4crA%
> 2Fvj3PqRRcZ0iNcRCOzdcpNvU%3D=0
> > pinningAndVersioning.md
> > >
> > >
> > > On Tue, Jan 3, 2017 at 12:26 PM, julio cesar sanchez <
> > jcesarmob...@gmail.com
> > >> wrote:
> > >
> > >> I have noticed that most of the plugins don't use the engine tags
> or
> > have
> > >> them set to cordova 3.0.0 or 3.1.0 which are very old.
> > >>
> > >> As we drop support for old iOS/Android versions when updating
> > cordova-ios
> > >> and cordova-android, what is our policy for iOS/Android versions
> > support in
> > >> plugins?
> > >>
> > >> Right now people can use the plugins on very old versions of iOS
> or
> > Android
> > >> despite we don't support them on the platforms, as the plugins
> engines
> > are
> > >> set to 3.0.0 or 3.1.0 on most of them.
> > >>
> > >> Should we start updating the engines to newer cordova versions?
> or even
> > >> fine grain it to cordova-ios/cordova-android versions?
> > >> I have noticed that we even have engines for iOS versions using
> > apple-ios
> > >> on the engine tag
> > >> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fgithub.com%2Fapache%2Fcordova-plugin-
> wkwebview-=02%7C01%7Cv-vlkoti%40microsoft.com%
> 7Ce2cfd36143c74c85e24408d434bdb765%7C72f988bf86f141af91ab2d7cd011
> db47%7C1%7C0%7C636191436803774697=yLXXSTq5hXfxS1yMhOePCv%
> 2F7xLuxpUyzOoTATnUU3bo%3D=0
> > >> engine/blob/master/plugin.xml#L35
> > >> (but not sure if this really does something as the plugin can be
> > >> installed/used in older iOS versions and what works or doesn't
> work is
> > >> controlled in the code)
> > >>
> > >> Or just say that the old Android/iOS version is not supported by
> Cordova
> > >> anymore if someone complains about a plugin not working?
> > >>
> >
> > 
> -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>
>
>
>
>

Re: [Vote] 6.1.1 Android Release

[Joe Bowser]

I vote +1:
* Created an app using the CLI
* Ran Mobilespec (debugged mobilespec)
* Installed and removed plugins to make sure the functionality affected was
fixed.

On Wed, Jan 4, 2017 at 11:47 AM, Karen Tran  wrote:

> I vote +1:
> * Created and ran a plain app
> * Ran app from Android Studio
> * Ran mobilespec
>
> On Tue, Jan 3, 2017 at 9:03 PM, Steven Gill 
> wrote:
>
> > Please review and vote on this 6.1.1 Android Release
> > by replying to this email (and keep discussion on the DISCUSS thread)
> >
> > Release issue: https://issues.apache.org/jira/browse/CB-12314
> >
> > The archive has been published to
> > dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-12314
> >
> >
> > The package was published from its corresponding git tag:
> > cordova-android: 6.1.1 (96457effbc)
> >
> > Note that you can test it out via:
> >
> > cordova platform add https://github.com/apache/cordova-android#6.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
> > * Ran mobilespec
> >
>

Re: [Discuss] cordova android@6.1.1 patch release

[Joe Bowser]

Sounds good.

On Tue, Jan 3, 2017 at 10:23 AM, Steven Gill  wrote:

> Going to start this patch release today. It will make our CI pass again for
> cordova cli + lib.
>
> https://issues.apache.org/jira/browse/CB-12314
>

Re: CB-12099 (android) SplashScreen Screen Flicker

[Joe Bowser]

Comments are inline

On Tue, Dec 20, 2016 at 1:19 PM, Sergey Shakhnazarov <dase...@apache.org>
wrote:
>
>
> > 3. I'm not sure why we need the prepare step and why the drawable's
> colour can't be changed programmatically in Java instead of pulling it from
> the config.xml in prepare.js, which isn't guaranteed to work in earlier
> versions of Cordova.
> Yes we can change the bg color programmatically but it will be too late as
> there will be a visible color change from initial color defined in layout.
>
>
Then we really shouldn't be adding this.  I don't think that this issue is
serious enough to warrant a major version change right now.  Perhaps if we
have a few major changes to the API that we want to make pending, we can
then revisit it.

I don't think it's possible to address "1." taking into account the flicker
> issue is reproducing even without the plugin added - there is a black
> screen before view is being filled with BackgroundColor.
>
> I think I've noticed another bug right now, which occurs when we have NO
> splashscreen plugin added - in this case there's a flash of BackgroundColor
> between app launch and webview showing.
>
>
That's the webview being too slow to render, and it's existed since the
project started.  Unfortunately that can't be fixed, but only mitigated by
using a Splashscreen and having an application that doesn't take all day to
render.  This is why the background color is a preference that you can set
in config.xml in the first place.

BTW: Every application starts out the same way on Android, and this is only
visible if there's something slowing down or blocking the application from
rendering (for example, when you debug the application, you will see a
black screen with the dialog saying that the debugger is connecting).  I
know that we do some hide/show magic with the WebView itself on the
Activity to try and prevent a white flash from appearing before the page is
rendered, so it's possible that the application is taking too long to draw
or the UI thread is blocked on something.  I've seen Unity applications
(OK, Just Pokemon Go, but there have to be others) crash and leave with
just a black screen, so this is not a problem unique to PhoneGap/Cordova.

Best regards,
> Sergey.
>
>
> On Sat, Dec 17, 2016 at 10:34 AM, Joe Bowser <bows...@gmail.com> wrote:
>
> > OK, I read the PR, and I'll admit that I misunderstood part of the
> > problem.  I have a few concerns about this change:
> >
> > 1. Why does Android need to have a PR at all? The splashscreen plugin can
> > use edit-config tag to change the manifest to add the theme, which it
> > really should anyway and the XML files can be copied by the plugin.xml.
> > 2. The bug refers to the flicker, which I haven't seen in quite a while,
> > but can be attributed to the splashscreen disappearing at the wrong time
> > and the WebView not being made visible or not rendering properly.
> CB-12099
> > explicitly refers to the weird behaviour of the SplashScreenDelay not
> > actually being followed, which is why I made my initial comment. It's not
> > its own bug, but a part of CB-12099
> > 3. I'm not sure why we need the prepare step and why the drawable's
> colour
> > can't be changed programmatically in Java instead of pulling it from the
> > config.xml in prepare.js, which isn't guaranteed to work in earlier
> > versions of Cordova.
> >
> > I know this seems like more work, but I think it's possible to do this
> > without having to change the Plugin API for Splashscreen, also doing so
> > will also work on existing versions of Cordova, and this fix would
> probably
> > consist of a major version bump, because the new splashscreen wouldn't
> work
> > on the old versions of Cordova-Android.
> >
> > On Fri, Dec 16, 2016 at 10:34 PM, Sergey Shakhnazarov <
> dase...@apache.org>
> > wrote:
> >
> >> Hello Joe,
> >>
> >> Could you please elaborate - is there a Jira item corresponding to that
> >> duration issue?
> >>
> >> Thanks,
> >> Sergey.
> >>
> >> 16 Дек 2016 г. 23:38 пользователь "Joe Bowser" <bows...@gmail.com>
> >> написал:
> >>
> >> I think we should figure out why the duration of the Splashscreen is
> >> messed
> >> up before we start messing with the background colour of the
> application,
> >> especially since the last time we did that, we broke Hello World!
> >>
> >> On Fri, Dec 16, 2016 at 11:32 AM, Sergey Shakhnazarov <
> dase...@apache.org
> >> >
> >> wrote:
> >>
> >> > Hi guys!
> >> >
> >> >
> 

Re: CB-12099 (android) SplashScreen Screen Flicker

[Joe Bowser]

OK, I read the PR, and I'll admit that I misunderstood part of the
problem.  I have a few concerns about this change:

1. Why does Android need to have a PR at all? The splashscreen plugin can
use edit-config tag to change the manifest to add the theme, which it
really should anyway and the XML files can be copied by the plugin.xml.
2. The bug refers to the flicker, which I haven't seen in quite a while,
but can be attributed to the splashscreen disappearing at the wrong time
and the WebView not being made visible or not rendering properly.  CB-12099
explicitly refers to the weird behaviour of the SplashScreenDelay not
actually being followed, which is why I made my initial comment. It's not
its own bug, but a part of CB-12099
3. I'm not sure why we need the prepare step and why the drawable's colour
can't be changed programmatically in Java instead of pulling it from the
config.xml in prepare.js, which isn't guaranteed to work in earlier
versions of Cordova.

I know this seems like more work, but I think it's possible to do this
without having to change the Plugin API for Splashscreen, also doing so
will also work on existing versions of Cordova, and this fix would probably
consist of a major version bump, because the new splashscreen wouldn't work
on the old versions of Cordova-Android.

On Fri, Dec 16, 2016 at 10:34 PM, Sergey Shakhnazarov <dase...@apache.org>
wrote:

> Hello Joe,
>
> Could you please elaborate - is there a Jira item corresponding to that
> duration issue?
>
> Thanks,
> Sergey.
>
> 16 Дек 2016 г. 23:38 пользователь "Joe Bowser" <bows...@gmail.com>
> написал:
>
> I think we should figure out why the duration of the Splashscreen is messed
> up before we start messing with the background colour of the application,
> especially since the last time we did that, we broke Hello World!
>
> On Fri, Dec 16, 2016 at 11:32 AM, Sergey Shakhnazarov <dase...@apache.org>
> wrote:
>
> > Hi guys!
> >
> >
> >
> > There’s an issue with Android splashscreen that every app has a black
> flash
> > on start [1].
> >
> > I propose to fix this using the android:windowBackground composed as
> splash
> > image (which we use in splashscreen plugin) laid on top of
> > SplashScreenBackgroundColor
> > [2] (this preference is supported on Windows only as of now and will be
> > particularly useful for transparent images).
> >
> > I would appreciate any feedback on the proposal and prototype
> > implementation [3, 4].
> >
> >
> >
> > [1]: https://issues.apache.org/jira/browse/CB-12099
> >
> > [2]: https://cordova.apache.org/docs/en/dev/config_ref/index.html
> >
> > [3]: https://github.com/daserge/cordova-android/tree/CB-12099
> >
> > [4]: https://github.com/daserge/cordova-plugin-splashscreen/
> tree/CB-12099
> >
> >
> >
> > Please let me know if you have any questions or considerations.
> >
> >
> > Best regards,
> >
> > Sergey Shakhnazarov,
> >
> > Akvelon developer.
> >
>

Re: CB-12099 (android) SplashScreen Screen Flicker

[Joe Bowser]

I think we should figure out why the duration of the Splashscreen is messed
up before we start messing with the background colour of the application,
especially since the last time we did that, we broke Hello World!

On Fri, Dec 16, 2016 at 11:32 AM, Sergey Shakhnazarov 
wrote:

> Hi guys!
>
>
>
> There’s an issue with Android splashscreen that every app has a black flash
> on start [1].
>
> I propose to fix this using the android:windowBackground composed as splash
> image (which we use in splashscreen plugin) laid on top of
> SplashScreenBackgroundColor
> [2] (this preference is supported on Windows only as of now and will be
> particularly useful for transparent images).
>
> I would appreciate any feedback on the proposal and prototype
> implementation [3, 4].
>
>
>
> [1]: https://issues.apache.org/jira/browse/CB-12099
>
> [2]: https://cordova.apache.org/docs/en/dev/config_ref/index.html
>
> [3]: https://github.com/daserge/cordova-android/tree/CB-12099
>
> [4]: https://github.com/daserge/cordova-plugin-splashscreen/tree/CB-12099
>
>
>
> Please let me know if you have any questions or considerations.
>
>
> Best regards,
>
> Sergey Shakhnazarov,
>
> Akvelon developer.
>

Re: camera plugin - target bigger than original picture

[Joe Bowser]

+1 to this PR

On Mon, Oct 10, 2016 at 10:38 AM, Shazron  wrote:

> +1 but with caveats as I outlined in the PR.
>
> On Mon, Oct 10, 2016 at 10:16 AM, julio cesar sanchez <
> jcesarmob...@gmail.com> wrote:
>
> > I was the one who asked for the email as I think we should discuss it
> > before merging.
> >
> > I agree with Fares idea, if the height or width are greater than the
> > originals then I think we shouldn't upscale the image and return the
> > original image instead.
> > But that should be documented (current PR doesn't document it).
> >
> > So +1 for the PR.
> >
> >
> >
> > 2016-10-10 11:34 GMT+02:00 Fares de Marki :
> >
> > > Hi,
> > >
> > > I sent a pull request for the cordova camera plugin :
> > > https://github.com/apache/cordova-plugin-camera/pull/238
> > >
> > > I was asked to send you an email.
> > > This pull request prevents the plugin from creating bigger pictures
> than
> > > original ones.
> > >
> > > Thanks
> > >
> > >
> > > Fares Hantous
> > > Marki
> > > http://markiapp.com/ 
> > >
> > >
> > >
> > >
> >
>

Re: [VOTE] cordova-android@6.1.0 Release

[Joe Bowser]

The vote has now closed. The results are:

Positive Binding Votes: 3.

Joe Bowser
Shazron Abdullah
Karen Tran

The vote has passed.

On Mon, Nov 7, 2016 at 11:08 AM, Karen Tran <ktop...@gmail.com> wrote:

> I vote +1:
> * Created a new app using the android platform and ran on device
> * Import to Android Studio and ran from Android Studio
> * Upgraded an old version to the newest platform version
>
> On Fri, Nov 4, 2016 at 6:23 PM, Shazron <shaz...@gmail.com> wrote:
>
> > 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 tests passed (AppVeyor and Travis CI)
> > * Created and emulated new app using the platform
> >
> > On Thu, Nov 3, 2016 at 12:57 PM, Joe Bowser <bows...@gmail.com> wrote:
> >
> > > Please review and vote on this 6.1.0 Android Release
> > > by replying to this email (and keep discussion on the DISCUSS thread)
> > >
> > > Release issue: https://issues.apache.org/jira/browse/CB-12109
> > >
> > > The archive has been published to
> > > dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-12109
> > >
> > > The package was published from its corresponding git tag:
> > >
> > > cordova-android: 6.1.0 (e856613787)
> > >
> > > ote that you can test it out via:
> > >
> > > cordova platform add https://github.com/apache/
> cordova-android#6.1.0
> > >
> > > 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 tests were correct and passed, and that appveyor was green
> > > when repo was tagged.
> > >
> >
>

Re: [DISCUSS] Cordova-Android 6.1 Release

[Joe Bowser]

It would be really great if the community would come through on this one
and vote on a release.

On Mon, Nov 7, 2016 at 7:45 AM, Shazron <shaz...@gmail.com> wrote:

> Android 6.1 needs one more vote!
>
> On Thursday, November 3, 2016, Joe Bowser <bows...@gmail.com> wrote:
>
> > Hey
> >
> > We're getting some hiccups on the 6.1 Android Release with Travis.  I'm
> not
> > able to reproduce on the local machine, so we think that it's a travis
> > error with updating packages, so we're going to go ahead with the vote
> > again.  Sorry for the delay today.
> >
> > On Wed, Nov 2, 2016 at 11:46 AM, Joe Bowser <bows...@gmail.com
> > <javascript:;>> wrote:
> >
> > > Hey
> > >
> > > Look under "What to Test" on this document to see the basics of What to
> > > Test:
> > > https://github.com/apache/cordova-coho/blob/master/docs/
> > > platforms-release-process.md
> > >
> > > However, this will obviously not catch everything, so people who
> actually
> > > use the CLI to do development should probably try to make an app with
> the
> > > new version once it's up for voting, or even before by checking out the
> > > repository and installing it.
> > >
> > > On Wed, Nov 2, 2016 at 11:26 AM, Simon MacDonald <
> > > simon.macdon...@gmail.com <javascript:;>> wrote:
> > >
> > >> Sounds good Joe. Can you re-post the official process/doc on how to
> > verify
> > >> a cordova-android release for those who may be doing it for the first
> > >> time?
> > >>
> > >>
> > >> Simon Mac Donald
> > >> http://simonmacdonald.com
> > >>
> > >> On Wed, Nov 2, 2016 at 2:12 PM, Shazron <shaz...@gmail.com
> > <javascript:;>> wrote:
> > >>
> > >> > +1
> > >> > For those not using Android daily, also give us guidance on testing
> > >> areas
> > >> > of focus
> > >> >
> > >> > On Wed, Nov 2, 2016 at 9:06 AM, Joe Bowser <bows...@gmail.com
> > <javascript:;>> wrote:
> > >> >
> > >> > > Hey
> > >> > >
> > >> > > While people have been talking about how critical their fix is for
> > >> > Cordova,
> > >> > > I actually found a critical issue that we missed in Cordova w.r.t
> > >> builds
> > >> > > failing with Android Studio based projects, so I rushed some
> commits
> > >> in
> > >> > for
> > >> > > Cordova-Android 6.1 release.
> > >> > >
> > >> > > The reason that this is 6.1 and 6.01 is because we're also bumping
> > the
> > >> > API
> > >> > > level to 25 so that we can support the latest version of Android
> out
> > >> in
> > >> > the
> > >> > > wild, which is on the Google Pixel.  There's no real difference
> > >> between
> > >> > the
> > >> > > two, and the current beta is actually 7.1.1.
> > >> > >
> > >> > > BTW, it would be helpful if more people tested this release before
> > we
> > >> go
> > >> > > and vote on it so we don't have to do a 6.1.1.  The Apache process
> > >> makes
> > >> > > releasing time-intensive, and I'd rather be working instead of
> > waiting
> > >> > > around for things to be released over and over again.
> > >> > >
> > >> > > What are people's thoughts on this?
> > >> > >
> > >> > > Joe
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>

[DISCUSS] cordova-plugin-camera release

[Joe Bowser]

Hey

So, now that we have Cordova Android 6.1 and cordova-plugin-compat in vote
stage, we should also look at releasing the Camera so that it can finally
work on Android 7.0 and higher when targeting that OS.

What do people think about getting a vote for this plugin happening after
compat is done?

Joe

[VOTE] cordova-android@6.1.0 Release

[Joe Bowser]

Please review and vote on this 6.1.0 Android Release
by replying to this email (and keep discussion on the DISCUSS thread)

Release issue: https://issues.apache.org/jira/browse/CB-12109

The archive has been published to
dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-12109

The package was published from its corresponding git tag:

cordova-android: 6.1.0 (e856613787)

ote that you can test it out via:

cordova platform add https://github.com/apache/cordova-android#6.1.0

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 tests were correct and passed, and that appveyor was green
when repo was tagged.

Re: [DISCUSS] Cordova-Android 6.1 Release

[Joe Bowser]

Hey

We're getting some hiccups on the 6.1 Android Release with Travis.  I'm not
able to reproduce on the local machine, so we think that it's a travis
error with updating packages, so we're going to go ahead with the vote
again.  Sorry for the delay today.

On Wed, Nov 2, 2016 at 11:46 AM, Joe Bowser <bows...@gmail.com> wrote:

> Hey
>
> Look under "What to Test" on this document to see the basics of What to
> Test:
> https://github.com/apache/cordova-coho/blob/master/docs/
> platforms-release-process.md
>
> However, this will obviously not catch everything, so people who actually
> use the CLI to do development should probably try to make an app with the
> new version once it's up for voting, or even before by checking out the
> repository and installing it.
>
> On Wed, Nov 2, 2016 at 11:26 AM, Simon MacDonald <
> simon.macdon...@gmail.com> wrote:
>
>> Sounds good Joe. Can you re-post the official process/doc on how to verify
>> a cordova-android release for those who may be doing it for the first
>> time?
>>
>>
>> Simon Mac Donald
>> http://simonmacdonald.com
>>
>> On Wed, Nov 2, 2016 at 2:12 PM, Shazron <shaz...@gmail.com> wrote:
>>
>> > +1
>> > For those not using Android daily, also give us guidance on testing
>> areas
>> > of focus
>> >
>> > On Wed, Nov 2, 2016 at 9:06 AM, Joe Bowser <bows...@gmail.com> wrote:
>> >
>> > > Hey
>> > >
>> > > While people have been talking about how critical their fix is for
>> > Cordova,
>> > > I actually found a critical issue that we missed in Cordova w.r.t
>> builds
>> > > failing with Android Studio based projects, so I rushed some commits
>> in
>> > for
>> > > Cordova-Android 6.1 release.
>> > >
>> > > The reason that this is 6.1 and 6.01 is because we're also bumping the
>> > API
>> > > level to 25 so that we can support the latest version of Android out
>> in
>> > the
>> > > wild, which is on the Google Pixel.  There's no real difference
>> between
>> > the
>> > > two, and the current beta is actually 7.1.1.
>> > >
>> > > BTW, it would be helpful if more people tested this release before we
>> go
>> > > and vote on it so we don't have to do a 6.1.1.  The Apache process
>> makes
>> > > releasing time-intensive, and I'd rather be working instead of waiting
>> > > around for things to be released over and over again.
>> > >
>> > > What are people's thoughts on this?
>> > >
>> > > Joe
>> > >
>> >
>>
>
>

Re: [VOTE] Cordova-Android 6.1.0 Release

[Joe Bowser]

-1

Vote is cancelled.

On Thu, Nov 3, 2016 at 10:34 AM, Joe Bowser <bows...@gmail.com> wrote:

> Please review and vote on this 6.1.0 Android Release
> by replying to this email (and keep discussion on the DISCUSS thread)
>
> Release issue: https://issues.apache.org/jira/browse/CB-12109
>
> The archive has been published to 
> dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-12109
>
> The package was published from its corresponding git tag:*
> cordova-android: 6.1.0 (7e54af75d8)*
>
>
> Note that you can test it out via:
>
> cordova platform add https://github.com/apache/cordova-android#6.1.0
>
> 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
>
>

[VOTE] Cordova-Android 6.1.0 Release

[Joe Bowser]

Please review and vote on this 6.1.0 Android Release
by replying to this email (and keep discussion on the DISCUSS thread)

Release issue: https://issues.apache.org/jira/browse/CB-12109

The archive has been published to
dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-12109

The package was published from its corresponding git tag:*
cordova-android: 6.1.0 (7e54af75d8)*


Note that you can test it out via:

cordova platform add https://github.com/apache/cordova-android#6.1.0

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

RE: How to setup cordova mobilespec with CLI

[Joe Bowser]

Except for the fact that it doesn't actually build in Android Studio.  It
would be great if people could build and run Android applications using
Crosswalk in the IDE.

There was a thread about the deprecated NDK switch put in the CLI months
ago and I would like to be able to get rid of it at some point.

On Nov 2, 2016 8:08 PM, "Fu, Junwei" <junwei...@intel.com> wrote:

> The Cordova project of Crosswalk plugin can be compiled with the
> documentation http://cordova.apache.org/docs/en/latest/guide/
> platforms/android/index.html#opening-a-project-in-android-studio , it
> also can be debugged for Java code with Android studio.  So how do you use
> Crosswalk with Android Studio?
>
> -----Original Message-
> From: Joe Bowser [mailto:bows...@gmail.com]
> Sent: Thursday, November 03, 2016 9:52 AM
> To: dev
> Subject: Re: How to setup cordova mobilespec with CLI
>
> I just realized that it's not the whole answer.  Once you fetch the
> repositories and clone them down all in a cordova directory, you should
> then be able to run the command, since you'll have all the repositories
> locally.  You should also make sure to get the cordova-plugin-compat plugin
> that allows plugins to work with earlier Cordova versions temporarily until
> we move the classes directly into Cordova proper.
>
> BTW: This is a bit off-topic, but is there any update on when we can use
> Crosswalk with Android Studio?  We're currently using a flag to allow it to
> keep compiling with Cordova, but it would be good to be able to debug a
> project in Android Studio that uses Crosswalk.
>
> On Wed, Nov 2, 2016 at 6:47 PM, Joe Bowser <bows...@gmail.com> wrote:
>
> > Hey
> >
> > You should start with coho, then use that to fetch the rest of the
> > directories as found here:
> > https://github.com/apache/cordova-coho
> >
> > It's our repo-management tool for dealing with all the git repositories.
> > It's similar to how repo is used with AOSP, but a bit different in
> > that it's more focused on fetching repos and processing releases with
> Javascript.
> >
> > BTW: Our master branch isn't on github, it's actually on the ASF
> > repositories which GitHub mirrors.  Here's an example of the git-web
> > interface for Cordova Android:
> > https://git1-us-west.apache.org/repos/asf?p=cordova-android.git
> >
> > But Coho pulls those, and changes happen directly on that repository
> > and find their way back to the GitHub mirrors.  We use the github
> > mirrors to process patches.
> >
> > It would be a very good idea for the mobilespec documentation to be
> > updated, since it seems to be misleading.
> >
> >
> > On Wed, Nov 2, 2016 at 6:37 PM, Fu, Junwei <junwei...@intel.com> wrote:
> >
> >>
> >> Hi All,
> >>
> >> The steps of following the documentation<https://github.c
> >> om/apache/cordova-mobile-spec> are too complex and All of repos need
> >> to pull the master branch, Do we have steps to build mobile spec with
> >> released CLI.
> >>
> >>
> >> $ git clone https://github.com/apache/cordova-mobile-spec.git
> >>
> >> $ git clone https://github.com/apache/cordova-lib.git
> >>
> >> $ git clone https://github.com/apache/cordova-cli.git
> >>
> >> $ git clone https://github.com/apache/cordova-plugman.git
> >>
> >> $ git clone https://github.com/apache/cordova-js.git
> >>
> >> $ git clone https://github.com/apache/cordova-coho.git
> >>
> >> $ git clone https://github.com/apache/cordova-android.git
> >>
> >> $ cordova-mobile-spec/createmobilespec/createmobilespec.js -android
> >>
> >> $ cd mobilespec
> >>
> >> $./cordova run android
> >>
> >>
> >>
> >> Thanks,
> >>
> >> Junwei.
> >>
> >>
> >>
> >
>

Re: How to setup cordova mobilespec with CLI

[Joe Bowser]

I just realized that it's not the whole answer.  Once you fetch the
repositories and clone them down all in a cordova directory, you should
then be able to run the command, since you'll have all the repositories
locally.  You should also make sure to get the cordova-plugin-compat plugin
that allows plugins to work with earlier Cordova versions temporarily until
we move the classes directly into Cordova proper.

BTW: This is a bit off-topic, but is there any update on when we can use
Crosswalk with Android Studio?  We're currently using a flag to allow it to
keep compiling with Cordova, but it would be good to be able to debug a
project in Android Studio that uses Crosswalk.

On Wed, Nov 2, 2016 at 6:47 PM, Joe Bowser <bows...@gmail.com> wrote:

> Hey
>
> You should start with coho, then use that to fetch the rest of the
> directories as found here:
> https://github.com/apache/cordova-coho
>
> It's our repo-management tool for dealing with all the git repositories.
> It's similar to how repo is used with AOSP, but a bit different in that
> it's more focused on fetching repos and processing releases with Javascript.
>
> BTW: Our master branch isn't on github, it's actually on the ASF
> repositories which GitHub mirrors.  Here's an example of the git-web
> interface for Cordova Android:
> https://git1-us-west.apache.org/repos/asf?p=cordova-android.git
>
> But Coho pulls those, and changes happen directly on that repository and
> find their way back to the GitHub mirrors.  We use the github mirrors to
> process patches.
>
> It would be a very good idea for the mobilespec documentation to be
> updated, since it seems to be misleading.
>
>
> On Wed, Nov 2, 2016 at 6:37 PM, Fu, Junwei <junwei...@intel.com> wrote:
>
>>
>> Hi All,
>>
>> The steps of following the documentation<https://github.c
>> om/apache/cordova-mobile-spec> are too complex and All of repos need to
>> pull the master branch, Do we have steps to build mobile spec with released
>> CLI.
>>
>>
>> $ git clone https://github.com/apache/cordova-mobile-spec.git
>>
>> $ git clone https://github.com/apache/cordova-lib.git
>>
>> $ git clone https://github.com/apache/cordova-cli.git
>>
>> $ git clone https://github.com/apache/cordova-plugman.git
>>
>> $ git clone https://github.com/apache/cordova-js.git
>>
>> $ git clone https://github.com/apache/cordova-coho.git
>>
>> $ git clone https://github.com/apache/cordova-android.git
>>
>> $ cordova-mobile-spec/createmobilespec/createmobilespec.js -android
>>
>> $ cd mobilespec
>>
>> $./cordova run android
>>
>>
>>
>> Thanks,
>>
>> Junwei.
>>
>>
>>
>

Re: [VOTE] cordova-plugin-compat@1.1.0 Release

[Joe Bowser]

I vote +1
* Ran coho check-licence
* Ran coho verify-archive
* Ran mobile-spec

On Wed, Nov 2, 2016 at 3:36 PM, Steven Gill  wrote:

> Please review and vote on the release of this cordova-plugin-compat release
> by replying to this email (and keep discussion on the DISCUSS thread)
>
> Release issue: https://issues.apache.org/jira/browse/CB-12110
>
> The plugins have been published to
> dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-12110/
>
> The packages were published from their corresponding git tags:
> cordova-plugin-compat: 1.1.0 (dd416cc807)
>
> Upon a successful vote I will upload the archives to dist/, upload
> them to npm, and post the corresponding blog post.
>
> Voting guidelines:
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
> How to vote on a plugins release at
> https://github.com/apache/cordova-coho/blob/master/docs/
> plugins-release-process.md#voting
>
> 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
> * Ran mobile-spec
>

Re: [DISCUSS] Cordova-Android 6.1 Release

[Joe Bowser]

Hey

Look under "What to Test" on this document to see the basics of What to
Test:
https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md

However, this will obviously not catch everything, so people who actually
use the CLI to do development should probably try to make an app with the
new version once it's up for voting, or even before by checking out the
repository and installing it.

On Wed, Nov 2, 2016 at 11:26 AM, Simon MacDonald <simon.macdon...@gmail.com>
wrote:

> Sounds good Joe. Can you re-post the official process/doc on how to verify
> a cordova-android release for those who may be doing it for the first time?
>
>
> Simon Mac Donald
> http://simonmacdonald.com
>
> On Wed, Nov 2, 2016 at 2:12 PM, Shazron <shaz...@gmail.com> wrote:
>
> > +1
> > For those not using Android daily, also give us guidance on testing areas
> > of focus
> >
> > On Wed, Nov 2, 2016 at 9:06 AM, Joe Bowser <bows...@gmail.com> wrote:
> >
> > > Hey
> > >
> > > While people have been talking about how critical their fix is for
> > Cordova,
> > > I actually found a critical issue that we missed in Cordova w.r.t
> builds
> > > failing with Android Studio based projects, so I rushed some commits in
> > for
> > > Cordova-Android 6.1 release.
> > >
> > > The reason that this is 6.1 and 6.01 is because we're also bumping the
> > API
> > > level to 25 so that we can support the latest version of Android out in
> > the
> > > wild, which is on the Google Pixel.  There's no real difference between
> > the
> > > two, and the current beta is actually 7.1.1.
> > >
> > > BTW, it would be helpful if more people tested this release before we
> go
> > > and vote on it so we don't have to do a 6.1.1.  The Apache process
> makes
> > > releasing time-intensive, and I'd rather be working instead of waiting
> > > around for things to be released over and over again.
> > >
> > > What are people's thoughts on this?
> > >
> > > Joe
> > >
> >
>

[DISCUSS] Cordova-Android 6.1 Release

[Joe Bowser]

Hey

While people have been talking about how critical their fix is for Cordova,
I actually found a critical issue that we missed in Cordova w.r.t builds
failing with Android Studio based projects, so I rushed some commits in for
Cordova-Android 6.1 release.

The reason that this is 6.1 and 6.01 is because we're also bumping the API
level to 25 so that we can support the latest version of Android out in the
wild, which is on the Google Pixel.  There's no real difference between the
two, and the current beta is actually 7.1.1.

BTW, it would be helpful if more people tested this release before we go
and vote on it so we don't have to do a 6.1.1.  The Apache process makes
releasing time-intensive, and I'd rather be working instead of waiting
around for things to be released over and over again.

What are people's thoughts on this?

Joe

Re: Release cordova-android 6.0.1?

[Joe Bowser]

There are other things that need to be added, and there will probably be a
6.1 release in the next month.  I think doing a 6.0.1 release would be a
waste of time given how long the Apache process takes to go through a
release.  (About a week from start to end)

On Tue, Nov 1, 2016 at 9:10 AM, Victor Sosa <sosah.vic...@gmail.com> wrote:

> Got'cha!
> If there's nothing else outstanding that can be released, I agree with Joe.
>
> On Tue, Nov 1, 2016, 10:05 AM Joe Bowser <bows...@gmail.com> wrote:
>
> > I don't feel that this bug is worthy of a fix and can wait for other
> > patches such as the increase in API level.  If other people want to start
> > the process, that's fine, but I don't think that this is necessary at
> this
> > time.
> >
> > On Tue, Nov 1, 2016 at 8:48 AM, Victor Sosa <sosah.vic...@gmail.com>
> > wrote:
> >
> > > Hi Joe.
> > >
> > > Would you mind elaborate on why we need to wait for such support?
> > > For what I understand here is that it'll be a service release to fix
> the
> > > splash and icons problems rather than something bigger.
> > >
> > > On Tue, Nov 1, 2016 at 9:37 AM Joe Bowser <bows...@gmail.com> wrote:
> > >
> > > > -1
> > > >
> > > > We should wait until we get API 25 support added before doing another
> > > > release.
> > > >
> > > > On Tue, Nov 1, 2016 at 7:15 AM, Kerri Shotts <kerrisho...@gmail.com>
> > > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > ~ Kerri
> > > > >
> > > > > > On Oct 31, 2016, at 18:27, julio cesar sanchez <
> > > jcesarmob...@gmail.com
> > > > >
> > > > > wrote:
> > > > > >
> > > > > > On cordova-android 6.0.0 the splash and icons are broken (see
> > > > > > https://issues.apache.org/jira/browse/CB-12077)
> > > > > >
> > > > > > The PR has just been merged and I think we have to release it as
> > soon
> > > > as
> > > > > > possible as there has been 4 duplicated issues already
> > > > > >
> > > > > > WDYT?
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: Release cordova-android 6.0.1?

[Joe Bowser]

-1

We should wait until we get API 25 support added before doing another
release.

On Tue, Nov 1, 2016 at 7:15 AM, Kerri Shotts  wrote:

> +1
>
> ~ Kerri
>
> > On Oct 31, 2016, at 18:27, julio cesar sanchez 
> wrote:
> >
> > On cordova-android 6.0.0 the splash and icons are broken (see
> > https://issues.apache.org/jira/browse/CB-12077)
> >
> > The PR has just been merged and I think we have to release it as soon as
> > possible as there has been 4 duplicated issues already
> >
> > WDYT?
>
>

[DISCUSS] cordova-plugin-compat release

[Joe Bowser]

Hey

We need to release cordova-plugin-compat so that we can proceed with a
cordova-plugin-camera release now that we have cordova-android 6.0.0
released.

The main change that we have is a fallback method that we're using to fetch
the application ID out of the BuildConfig.  We need to use this for the
FilesProvider that we're using to get around the Nougat security fixes that
we added.

It would be great to get this in, since this is currently blocking all work
on accepting other android-based PRs.

What do people think?

Joe

Re: [VOTE] 4.3.0 iOS Release

[Joe Bowser]

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
* Ran mobile-spec against the Simulator


On Sat, Oct 22, 2016 at 2:40 AM, Shazron  wrote:

> Please review and vote on this 4.3.0 iOS Release
> by replying to this email (and keep discussion on the DISCUSS thread)
>
> Release issue: https://issues.apache.org/jira/browse/CB-12054
>
> The archive has been published to dist/dev:
> https://dist.apache.org/repos/dist/dev/cordova/CB-12054
>
> The package was published from its corresponding git tag:
> cordova-ios: 4.3.0 (a59101beb1)
>
> Note that you can test it out via:
>
> cordova platform add https://github.com/apache/cordova-ios#4.3.0
>
> 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
>

Re: [ANDROID] [XWalk] Crosswalk Webview Device Ready does not fire on Master

[Joe Bowser]

Yes.  That is expected.  There should probably be an engine tag.  Crosswalk
is it's own project, and it needs to figure out how it wants to handle
prior releases of Cordova.  We can only do so much for it before moving on.

On Mon, Oct 24, 2016 at 3:59 AM, Alexander Sorokin (Akvelon) <
v-als...@microsoft.com> wrote:

> Hey guys,
>
> Is it expected that after this bridge mode patch, crosswalk cannot be
> built for cordova-android@<=5.2.2?
>
> Thanks,
> Alexander Sorokin
>
> -Original Message-
> From: Steven Gill [mailto:stevengil...@gmail.com]
> Sent: Wednesday, October 19, 2016 2:39 AM
> To: dev@cordova.apache.org
> Subject: Re: [ANDROID] [XWalk] Crosswalk Webview Device Ready does not
> fire on Master
>
> Good work guys!
>
>
> On Tue, Oct 18, 2016 at 3:30 PM, Darryl Pogue <dvpdin...@gmail.com> wrote:
>
> > I've opened a PR to add that bridge mode:
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> > b.com%2Fcrosswalk-project%2Fcordova-plugin-=02%7C01%7Cv-alsoro%40
> > microsoft.com%7Cad92e55ff3874529b07008d3f7b014a8%7C72f988bf86f141af91a
> > b2d7cd011db47%7C1%7C0%7C636124308052342233=Z87SlZo88DK5eIRzTR09o
> > u3KtzbV8FgUl%2FkpsS4aRAQ%3D=0
> > crosswalk-webview/pull/100
> >
> > On 18 October 2016 at 15:23, Joe Bowser <bows...@gmail.com> wrote:
> > > BTW: I'd send a PR, but I still need Crosswalk to take over the repo
> > > from me, since they're developing off a fork of my repo.
> > >
> > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> > > hub.com%2Fcrosswalk-project%2Fcordova-plugin-crosswalk-webview=
> > > 02%7C01%7Cv-alsoro%40microsoft.com%7Cad92e55ff3874529b07008d3f7b014a
> > > 8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636124308052342233
> > > ata=kCF9YTv8kq6WGTD6MYuwtCuW7YIopqG%2BoHx6804EUlA%3D=0
> > >
> > >
> > >
> > > On Tue, Oct 18, 2016 at 3:08 PM, Joe Bowser <bows...@gmail.com> wrote:
> > >
> > >> Hey
> > >>
> > >> I just realized what the problem is:
> > >>
> > >> Crosswalk is missing this method, which adds the bridge mode, since
> > >> the bridge mode defaults back ONLINE_EVENT in the event that
> > >> EVAL_BRIDGE
> > isn't
> > >> supported, this will break every time.  We need the following line
> > added to
> > >> Crosswalk.
> > >>
> > >> nativeToJsMessageQueue.addBridgeMode(new
> > >> NativeToJsMessageQueue.EvalBridgeMode(this,
> > cordova));
> > >>
> > >>
> > >> On Tue, Oct 18, 2016 at 2:32 PM, Joe Bowser <bows...@gmail.com>
> wrote:
> > >>
> > >>> Correct.  Without that method, it won't even compile.
> > >>>
> > >>>
> > >>> On Tue, Oct 18, 2016 at 2:31 PM, Darryl Pogue
> > >>> <dvpdin...@gmail.com>
> > >>> wrote:
> > >>>
> > >>>> On 18 October 2016 at 14:24, Joe Bowser <bows...@gmail.com> wrote:
> > >>>> > Recently, we decided to change the default bridge from using
> > >>>> OnlineEvent to
> > >>>> > a JS_Exec bridge so that we can support a multi-webview use case.
> > The
> > >>>> > downside of this change is that it breaks on Crosswalk.  It's
> > >>>> > almost impossible to debug this since projects that include the
> > >>>> > Crosswalk
> > >>>> Webview
> > >>>> > break Android Studio.
> > >>>>
> > >>>> Just confirming, this is breaking on the latest version of
> > >>>> Crosswalk
> > >>>> (2.1.0) that has the evaluateJavascript method added to the
> > >>>> XWalkWebViewEngine class?
> > >>>>
> > >>>> -
> > >>>>  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
> >
> >
>

[Vote] 6.0.0 Android Release

[Joe Bowser]

Please review and vote on this 6.0.0 Android Release
by replying to this email (and keep discussion on the DISCUSS thread)

Release issue: https://issues.apache.org/jira/browse/CB-

The archive has been published to
dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-

The package was published from its corresponding git tag:
PASTE OUTPUT OF: coho print-tags -r android --tag 6.0.0

Note that you can test it out via:

cordova platform add https://github.com/apache/cordova-android#6.0.0

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

Re: [Discuss] Cordova-Android 6.0.x

[Joe Bowser]

BUMP!

OK, it seems that we've hit a few delays with pending releases and
cordova-common needing to be released, so based on this, I'll start the
long process of releasing this on Thursday if there's no objections.

On Mon, Oct 3, 2016 at 11:30 AM, Joe Bowser <bows...@gmail.com> wrote:

> OK, I recommend starting the vote thread after the Google announcement on
> Tuesday, so that I know everyone has read this.
>
> Joe
>
> On Thu, Sep 29, 2016 at 9:59 AM, Joe Bowser <bows...@gmail.com> wrote:
>
>> OK, so it's been a while.  I think we're ready for a release of this
>> soon.  I just have to fix up check_reqs so it works, and then we can move
>> forward with the Cordova-Android 6.0.0 release.
>>
>> Should we start the vote thread on Monday?
>>
>> On Tue, Sep 13, 2016 at 11:24 AM, Joe Bowser <bows...@gmail.com> wrote:
>>
>>> No, I have no intention of pulling that into this release, since the
>>> corresponding Android code caused performance issues due to numerous file
>>> reads.
>>>
>>> On Tue, Sep 13, 2016 at 11:21 AM, Darryl Pogue <dar...@dpogue.ca> wrote:
>>>
>>>> Just wanted to check whether this cordova-lib change was intended to get
>>>> pulled in as part of the Cordova Android 6 release:
>>>> https://github.com/apache/cordova-lib/pull/469
>>>>
>>>> If it is, I have an additional commit to add that fixes the JS spec
>>>> tests:
>>>> https://github.com/infil00p/cordova-lib/pull/1
>>>>
>>>>
>>>> On 13 September 2016 at 10:30, Joe Bowser <bows...@gmail.com> wrote:
>>>>
>>>> > OK, so it looks like all our ducks are lined up and we should be
>>>> ready for
>>>> > a 6.0 release pretty soon.  How do people feel about doing testing
>>>> this
>>>> > week, and getting the vote thread going on Monday? I know the vote
>>>> thread
>>>> > is only 72 hours, so I want a bit more testing on the major before we
>>>> do it
>>>> > because the PRs haven't been getting the attention that I wanted them
>>>> to.
>>>> >
>>>> > What do people think?
>>>> >
>>>> > On Thu, Sep 8, 2016 at 2:54 PM, Shazron <shaz...@gmail.com> wrote:
>>>> >
>>>> > > Ask Crosswalk to:
>>>> > > "To detach the fork and turn it into a standalone repository on
>>>> GitHub,
>>>> > > contact GitHub Support."
>>>> > >
>>>> > > From:
>>>> > > https://help.github.com/articles/why-are-my-
>>>> > contributions-not-showing-up-
>>>> > > on-my-profile/
>>>> > >
>>>> > >
>>>> > >
>>>> > > On Thu, Sep 8, 2016 at 2:46 PM, Joe Bowser <bows...@gmail.com>
>>>> wrote:
>>>> > >
>>>> > > > Hey
>>>> > > >
>>>> > > > So, this is exciting.  Things are broken on Master if you're
>>>> trying to
>>>> > > use
>>>> > > > Cordova with Jellybean.  Apparently we forgot to add a failsafe
>>>> for the
>>>> > > > bridge to go back to APIs lower than 19, so the bridge doesn't
>>>> work if
>>>> > > > you're targeting people still on Jellybean.  Unfortunately, we
>>>> still
>>>> > have
>>>> > > > to support Jellybean despite the fact that their jsToNativeBridge
>>>> is
>>>> > > > prompt.
>>>> > > >
>>>> > > > Also, I just realized that I can't send a PR to Crosswalk, since
>>>> I own
>>>> > > the
>>>> > > > initial crosswalk repo on GitHub. (Oops!)  This means that I need
>>>> > someone
>>>> > > > from the Crosswalk project to adopt these changes here to get
>>>> this to
>>>> > > work
>>>> > > > on Cordova-Android 6.0.0
>>>> > > >
>>>> > > > https://github.com/infil00p/cordova-crosswalk-engine/tree/
>>>> > > Crosswalk_Compat
>>>> > > >
>>>> > > > I'm tempted to nuke the thing in the near future, since the
>>>> Crosswalk
>>>> > > > Project should be managing the repository and their repository
>>>> should
>>>> > be
>>>> > &g

Re: [ANDROID] [XWalk] Crosswalk Webview Device Ready does not fire on Master

[Joe Bowser]

BTW: I'd send a PR, but I still need Crosswalk to take over the repo from
me, since they're developing off a fork of my repo.

https://github.com/crosswalk-project/cordova-plugin-crosswalk-webview



On Tue, Oct 18, 2016 at 3:08 PM, Joe Bowser <bows...@gmail.com> wrote:

> Hey
>
> I just realized what the problem is:
>
> Crosswalk is missing this method, which adds the bridge mode, since the
> bridge mode defaults back ONLINE_EVENT in the event that EVAL_BRIDGE isn't
> supported, this will break every time.  We need the following line added to
> Crosswalk.
>
> nativeToJsMessageQueue.addBridgeMode(new 
> NativeToJsMessageQueue.EvalBridgeMode(this, cordova));
>
>
> On Tue, Oct 18, 2016 at 2:32 PM, Joe Bowser <bows...@gmail.com> wrote:
>
>> Correct.  Without that method, it won't even compile.
>>
>>
>> On Tue, Oct 18, 2016 at 2:31 PM, Darryl Pogue <dvpdin...@gmail.com>
>> wrote:
>>
>>> On 18 October 2016 at 14:24, Joe Bowser <bows...@gmail.com> wrote:
>>> > Recently, we decided to change the default bridge from using
>>> OnlineEvent to
>>> > a JS_Exec bridge so that we can support a multi-webview use case.  The
>>> > downside of this change is that it breaks on Crosswalk.  It's almost
>>> > impossible to debug this since projects that include the Crosswalk
>>> Webview
>>> > break Android Studio.
>>>
>>> Just confirming, this is breaking on the latest version of Crosswalk
>>> (2.1.0) that has the evaluateJavascript method added to the
>>> XWalkWebViewEngine class?
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>>
>>>
>>
>

Re: [ANDROID] [XWalk] Crosswalk Webview Device Ready does not fire on Master

[Joe Bowser]

Hey

I just realized what the problem is:

Crosswalk is missing this method, which adds the bridge mode, since the
bridge mode defaults back ONLINE_EVENT in the event that EVAL_BRIDGE isn't
supported, this will break every time.  We need the following line added to
Crosswalk.

nativeToJsMessageQueue.addBridgeMode(new
NativeToJsMessageQueue.EvalBridgeMode(this, cordova));


On Tue, Oct 18, 2016 at 2:32 PM, Joe Bowser <bows...@gmail.com> wrote:

> Correct.  Without that method, it won't even compile.
>
>
> On Tue, Oct 18, 2016 at 2:31 PM, Darryl Pogue <dvpdin...@gmail.com> wrote:
>
>> On 18 October 2016 at 14:24, Joe Bowser <bows...@gmail.com> wrote:
>> > Recently, we decided to change the default bridge from using
>> OnlineEvent to
>> > a JS_Exec bridge so that we can support a multi-webview use case.  The
>> > downside of this change is that it breaks on Crosswalk.  It's almost
>> > impossible to debug this since projects that include the Crosswalk
>> Webview
>> > break Android Studio.
>>
>> Just confirming, this is breaking on the latest version of Crosswalk
>> (2.1.0) that has the evaluateJavascript method added to the
>> XWalkWebViewEngine class?
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>
>

Re: [ANDROID] [XWalk] Crosswalk Webview Device Ready does not fire on Master

[Joe Bowser]

Correct.  Without that method, it won't even compile.

On Tue, Oct 18, 2016 at 2:31 PM, Darryl Pogue <dvpdin...@gmail.com> wrote:

> On 18 October 2016 at 14:24, Joe Bowser <bows...@gmail.com> wrote:
> > Recently, we decided to change the default bridge from using OnlineEvent
> to
> > a JS_Exec bridge so that we can support a multi-webview use case.  The
> > downside of this change is that it breaks on Crosswalk.  It's almost
> > impossible to debug this since projects that include the Crosswalk
> Webview
> > break Android Studio.
>
> Just confirming, this is breaking on the latest version of Crosswalk
> (2.1.0) that has the evaluateJavascript method added to the
> XWalkWebViewEngine class?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

[ANDROID] [XWalk] Crosswalk Webview Device Ready does not fire on Master

[Joe Bowser]

Hey

Recently, we decided to change the default bridge from using OnlineEvent to
a JS_Exec bridge so that we can support a multi-webview use case.  The
downside of this change is that it breaks on Crosswalk.  It's almost
impossible to debug this since projects that include the Crosswalk Webview
break Android Studio.

So, should we proceed with the release knowing that the bridge is broken on
Crosswalk, or should we delay and try to fix this? I do not want to revert
this bridge change back, since it's really important that we have a more
robust bridge than the ONLINE_EVENT bridge that only works with single
webview applications.

Does anyone have any thoughts on this?

Joe

Re: Unity Plugin

[Joe Bowser]

Can you elaborate on what such a plugin would do?  Would this be a Unity
thing, or a Cordova thing?

On Mon, Oct 17, 2016 at 4:37 AM, Baltasar Sousa 
wrote:

> Do you have some official or not Cordova plugin to work in Unity3D?
>
> Best Regards,
> Baltasar Sousa
> :Dobsware
>

[Android] Project creation times and Gradle Respec

[Joe Bowser]

Hey

After looking over old issues, I decided to re-open this closed PR that
would allow us to support plugins written as Library Projects in Cordova.
The original reason I closed it was because it took too long to create a
project, but that was apparently caused by something else that we seemed to
have resolved, since it now takes only 1 second more to create this new
project than the old one, and that tbh is really just a margin of error in
my measurement.

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

Can other people hammer on this PR and tell me if they're noticing a slow
down in project creation times and the time it takes to install or remove
plugins? If not, I think we should add this to Cordova before we release
6.0.0.

Thanks

Joe

Re: Brief introduction Octavio Bokel

[Joe Bowser]

Hey

Can you send me a link to the PR so I can check the fix and make sure it's
not directly related to something that we already have committed/fixed?  We
currently have open PRs waiting to be merged into Camera once we finally
release Cordova-Android 6.0.0, which adds Nougat Support.

Thanks

Joe

On Wed, Oct 12, 2016 at 6:05 PM, Dobra9 (Octavio)  wrote:

> Hello.
>
> Just want to introduce myself.
>
> I am Octavio Bokel, and reticently fixed a bug in cordova-plugin-camera
> plugin for Android. I am CEO at Woopter (www.woopter.com) and this bug as
> direct affection our app.
>
> Since I tested and believe that it might help the community, I want to be
> able to do a pull request. After that, I want to continue contributing. I
> always liked the open source community philosophy.
>
> I could not subscribe to MarkMail yet since it is offline, I will do it
> soon.
>
> Thanks for your attention.
>
> Octavio Bokel
>

Re: [Android] onPause and onResume in the background on WebViews

[Joe Bowser]

Yeah, I think we shouldn't break users.  That said, I do think
PauseOnBackground should be a new feature.  I don't know if it'll land in
6.0 though, since I want to get the vote out this week.

On Tue, Oct 4, 2016 at 10:40 AM, Shazron <shaz...@gmail.com> wrote:

> We could like you said make a breaking change, but allow a preference to be
> set.
>
> We either make the preference backwards compatible (ie KeepRunning = true)
> so existing apps still work the same on Cordova-Android 6, or break
> backwards compatibility with KeepRunning=false as default.
>
> I would prefer to be backwards compatible, and not break users -- I think
> if they encounter a rejection they can just turn on this preference and
> re-submit.
>
>
>
> On Mon, Oct 3, 2016 at 4:23 PM, Joe Bowser <bows...@gmail.com> wrote:
>
> > Hey
> >
> > So, this bug came in and it's an important one:
> > https://issues.apache.org/jira/browse/CB-11935
> >
> > I've already accepted the fix for KeepRunning = false, but apps that
> start
> > in the background that have their JS running, and other apps probably
> need
> > to have their status managed.  I want to run onPause and onResume on the
> > webview every time the app pauses and resumes in Cordova, but I'm
> wondering
> > if that screws people up.  I know that we're at the eve of a major
> change,
> > so I can just break stuff, but it'd be good to get feedback before doing
> > it.
> >
> > What do people think? This is a pretty important change.
> >
> > Joe
> >
>

[Android] onPause and onResume in the background on WebViews

[Joe Bowser]

Hey

So, this bug came in and it's an important one:
https://issues.apache.org/jira/browse/CB-11935

I've already accepted the fix for KeepRunning = false, but apps that start
in the background that have their JS running, and other apps probably need
to have their status managed.  I want to run onPause and onResume on the
webview every time the app pauses and resumes in Cordova, but I'm wondering
if that screws people up.  I know that we're at the eve of a major change,
so I can just break stuff, but it'd be good to get feedback before doing
it.

What do people think? This is a pretty important change.

Joe

Re: [Discuss] Cordova-Android 6.0.x

[Joe Bowser]

OK, I recommend starting the vote thread after the Google announcement on
Tuesday, so that I know everyone has read this.

Joe

On Thu, Sep 29, 2016 at 9:59 AM, Joe Bowser <bows...@gmail.com> wrote:

> OK, so it's been a while.  I think we're ready for a release of this
> soon.  I just have to fix up check_reqs so it works, and then we can move
> forward with the Cordova-Android 6.0.0 release.
>
> Should we start the vote thread on Monday?
>
> On Tue, Sep 13, 2016 at 11:24 AM, Joe Bowser <bows...@gmail.com> wrote:
>
>> No, I have no intention of pulling that into this release, since the
>> corresponding Android code caused performance issues due to numerous file
>> reads.
>>
>> On Tue, Sep 13, 2016 at 11:21 AM, Darryl Pogue <dar...@dpogue.ca> wrote:
>>
>>> Just wanted to check whether this cordova-lib change was intended to get
>>> pulled in as part of the Cordova Android 6 release:
>>> https://github.com/apache/cordova-lib/pull/469
>>>
>>> If it is, I have an additional commit to add that fixes the JS spec
>>> tests:
>>> https://github.com/infil00p/cordova-lib/pull/1
>>>
>>>
>>> On 13 September 2016 at 10:30, Joe Bowser <bows...@gmail.com> wrote:
>>>
>>> > OK, so it looks like all our ducks are lined up and we should be ready
>>> for
>>> > a 6.0 release pretty soon.  How do people feel about doing testing this
>>> > week, and getting the vote thread going on Monday? I know the vote
>>> thread
>>> > is only 72 hours, so I want a bit more testing on the major before we
>>> do it
>>> > because the PRs haven't been getting the attention that I wanted them
>>> to.
>>> >
>>> > What do people think?
>>> >
>>> > On Thu, Sep 8, 2016 at 2:54 PM, Shazron <shaz...@gmail.com> wrote:
>>> >
>>> > > Ask Crosswalk to:
>>> > > "To detach the fork and turn it into a standalone repository on
>>> GitHub,
>>> > > contact GitHub Support."
>>> > >
>>> > > From:
>>> > > https://help.github.com/articles/why-are-my-
>>> > contributions-not-showing-up-
>>> > > on-my-profile/
>>> > >
>>> > >
>>> > >
>>> > > On Thu, Sep 8, 2016 at 2:46 PM, Joe Bowser <bows...@gmail.com>
>>> wrote:
>>> > >
>>> > > > Hey
>>> > > >
>>> > > > So, this is exciting.  Things are broken on Master if you're
>>> trying to
>>> > > use
>>> > > > Cordova with Jellybean.  Apparently we forgot to add a failsafe
>>> for the
>>> > > > bridge to go back to APIs lower than 19, so the bridge doesn't
>>> work if
>>> > > > you're targeting people still on Jellybean.  Unfortunately, we
>>> still
>>> > have
>>> > > > to support Jellybean despite the fact that their jsToNativeBridge
>>> is
>>> > > > prompt.
>>> > > >
>>> > > > Also, I just realized that I can't send a PR to Crosswalk, since I
>>> own
>>> > > the
>>> > > > initial crosswalk repo on GitHub. (Oops!)  This means that I need
>>> > someone
>>> > > > from the Crosswalk project to adopt these changes here to get this
>>> to
>>> > > work
>>> > > > on Cordova-Android 6.0.0
>>> > > >
>>> > > > https://github.com/infil00p/cordova-crosswalk-engine/tree/
>>> > > Crosswalk_Compat
>>> > > >
>>> > > > I'm tempted to nuke the thing in the near future, since the
>>> Crosswalk
>>> > > > Project should be managing the repository and their repository
>>> should
>>> > be
>>> > > > the canonical source for everything Crosswalk/Cordova related and
>>> not
>>> > my
>>> > > > prototype repo. :P
>>> > > >
>>> > > > So, is anyone using the stock webview for Jellybean, and should we
>>> > spend
>>> > > > time fixing this issue? We changed the webview because we found
>>> that
>>> > > using
>>> > > > multiple webviews in an application was falling apart, and we
>>> needed
>>> > this
>>> > > > change for stability so we knew which callbacks go to which
>>> instance of
>

Re: [Discuss] Cordova-Android 6.0.x

[Joe Bowser]

OK, so it's been a while.  I think we're ready for a release of this soon.
I just have to fix up check_reqs so it works, and then we can move forward
with the Cordova-Android 6.0.0 release.

Should we start the vote thread on Monday?

On Tue, Sep 13, 2016 at 11:24 AM, Joe Bowser <bows...@gmail.com> wrote:

> No, I have no intention of pulling that into this release, since the
> corresponding Android code caused performance issues due to numerous file
> reads.
>
> On Tue, Sep 13, 2016 at 11:21 AM, Darryl Pogue <dar...@dpogue.ca> wrote:
>
>> Just wanted to check whether this cordova-lib change was intended to get
>> pulled in as part of the Cordova Android 6 release:
>> https://github.com/apache/cordova-lib/pull/469
>>
>> If it is, I have an additional commit to add that fixes the JS spec tests:
>> https://github.com/infil00p/cordova-lib/pull/1
>>
>>
>> On 13 September 2016 at 10:30, Joe Bowser <bows...@gmail.com> wrote:
>>
>> > OK, so it looks like all our ducks are lined up and we should be ready
>> for
>> > a 6.0 release pretty soon.  How do people feel about doing testing this
>> > week, and getting the vote thread going on Monday? I know the vote
>> thread
>> > is only 72 hours, so I want a bit more testing on the major before we
>> do it
>> > because the PRs haven't been getting the attention that I wanted them
>> to.
>> >
>> > What do people think?
>> >
>> > On Thu, Sep 8, 2016 at 2:54 PM, Shazron <shaz...@gmail.com> wrote:
>> >
>> > > Ask Crosswalk to:
>> > > "To detach the fork and turn it into a standalone repository on
>> GitHub,
>> > > contact GitHub Support."
>> > >
>> > > From:
>> > > https://help.github.com/articles/why-are-my-
>> > contributions-not-showing-up-
>> > > on-my-profile/
>> > >
>> > >
>> > >
>> > > On Thu, Sep 8, 2016 at 2:46 PM, Joe Bowser <bows...@gmail.com> wrote:
>> > >
>> > > > Hey
>> > > >
>> > > > So, this is exciting.  Things are broken on Master if you're trying
>> to
>> > > use
>> > > > Cordova with Jellybean.  Apparently we forgot to add a failsafe for
>> the
>> > > > bridge to go back to APIs lower than 19, so the bridge doesn't work
>> if
>> > > > you're targeting people still on Jellybean.  Unfortunately, we still
>> > have
>> > > > to support Jellybean despite the fact that their jsToNativeBridge is
>> > > > prompt.
>> > > >
>> > > > Also, I just realized that I can't send a PR to Crosswalk, since I
>> own
>> > > the
>> > > > initial crosswalk repo on GitHub. (Oops!)  This means that I need
>> > someone
>> > > > from the Crosswalk project to adopt these changes here to get this
>> to
>> > > work
>> > > > on Cordova-Android 6.0.0
>> > > >
>> > > > https://github.com/infil00p/cordova-crosswalk-engine/tree/
>> > > Crosswalk_Compat
>> > > >
>> > > > I'm tempted to nuke the thing in the near future, since the
>> Crosswalk
>> > > > Project should be managing the repository and their repository
>> should
>> > be
>> > > > the canonical source for everything Crosswalk/Cordova related and
>> not
>> > my
>> > > > prototype repo. :P
>> > > >
>> > > > So, is anyone using the stock webview for Jellybean, and should we
>> > spend
>> > > > time fixing this issue? We changed the webview because we found that
>> > > using
>> > > > multiple webviews in an application was falling apart, and we needed
>> > this
>> > > > change for stability so we knew which callbacks go to which
>> instance of
>> > > > webview.  However, if people reviewed the patch requests, they would
>> > have
>> > > > noticed that this doesn't work on API 16. :(
>> > > >
>> > > > I'm going to go by the assumption that we want this fixed until I
>> hear
>> > > > otherwise for now.  That said, if people think it's reasonable to
>> > > recommend
>> > > > that people targeting Jellybean use Crosswalk, I'm cool with that as
>> > > well.
>> > > >
>> > > > Thoughts?
>> > > >
>> > > >
>> > > >
&