Re: Roadmap for next major versions

2018-07-02 Thread Shazron
Thanks Niklas,
Since you know what needs to be done or has been done with respect to
InAppBrowser - can you highlight any specific tasks or PRs that need to be
pulled in for IAB? I probably can't focus on getting anything except
WKWebView support for InAppBrowser this week (if I have the bandwidth, but
perhaps next week for a bit).

On Tue, Jul 3, 2018 at 1:30 PM Niklas Merz  wrote:

> That sounds great. Please don't forget InAppBrowser. I worked in getting
> WKwebview running in InAppBrowser a while ago and I happy to help, review
> and test these changes . Dave Alden did a good pull request on this.
>
> I flag like this sounds like a good way to test this in our app.
>
> Am 3. Juli 2018, 06:39, um 06:39, Shazron  schrieb:
> >I was thinking that the feature flag is just a convenience feature for
> >setting/removing (depends on if the flag is set/omitted):
> >
> >in
> >config.xml
> >
> >So something like this:
> >`cordova platform add ios --wkwebview` or something to that effect.
> >
> >My thinking is -- this would make manual testing easier, and remove
> >friction for testers in the interim, not to mention automated CI
> >setups. If
> >it's easier to test, perhaps more people would test it, at least that's
> >what I hope...
> >
> >Yeah the custom scheme thing, since it's iOS 11, we might have to
> >tackle
> >that once we drop iOS 10 support I suppose.
> >
> >On Tue, Jul 3, 2018 at 12:27 PM Darryl Pogue 
> >wrote:
> >
> >> Thanks Shazron!
> >>
> >> Regarding point 3 on your list, does that need to be a feature flag
> >> since the WebView engine is already controlled via a preference in
> >> config.xml? People should be able to opt-in that way just by adding a
> >> preference, and then in a future release we just change the default
> >> value for that preference, correct?
> >>
> >> From the Apple side, it sounds like they're very heavily encouraging
> >> the use of custom schemes instead of file:/// URLs for apps serving
> >> local files, but I think that wasn't introduced until iOS 11 which
> >> might be an issue for us.
> >>
> >> On Mon, Jul 2, 2018 at 8:36 PM Shazron  wrote:
> >> >
> >> > Thanks Darryl,
> >> > I'll be working on getting the WKWebView plugin up to snuff this
> >week
> >> (read
> >> > the comment thread in your doc).
> >> > 1. Review and resolve all existing PRs
> >> > 2. Integrate the WKWebView plugin into the cordova-ios repo
> >> > 3. Turn on WKWebView support via a feature flag (eventually this
> >will be
> >> > the default)
> >> >
> >> > I think no. 3 is a good way for interim testing versus having
> >long-lived
> >> > branches that might get out of sync. I don't think this will get
> >into the
> >> > same situation like `browserify` feature flag that was forgotten,
> >since
> >> we
> >> > intend to bake this in for sure.
> >> >
> >> > [CDVWebViewEngineProtocol support](
> >> >
> >>
> >
> https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/Public/CDVWebViewEngineProtocol.h
> >> )
> >> > so we can swap in any webview engine will remain unchanged.
> >> >
> >> > On Tue, Jun 26, 2018 at 12:43 PM Darryl Pogue 
> >wrote:
> >> >
> >> > > Hi folks,
> >> > >
> >> > > As we've been discussing dropping node 4 support and how that
> >requires
> >> > > a major version bump, we should review what had already been on
> >the
> >> > > pile for next majors and what we want on the pile.
> >> > >
> >> > > I've started a Google Doc scratchpad to loosely organize
> >high-level
> >> > > goals for the various modules, and then we can start breaking
> >them
> >> > > down into JIRA tasks and putting them on the sprint boards:
> >> > >
> >> > >
> >>
> >
> https://docs.google.com/document/d/1P81YqXJbblIhzWWjWIE5AqjJvE29b1vHJX79TuIjyPM/edit#
> >> > >
> >> > > We know that iOS 12 and Android P are both likely coming in the
> >fall,
> >> > > so it might make sense to target our release to line up around
> >that
> >> > > time and make sure we support both of the new platform versions.
> >I
> >> > > don't love the idea of waiting that long, but let's be realistic
> >about
> >> > > what we can try to achieve.
> >> > >
> >> > > ~Darryl
> >> > >
> >> > >
> >-
> >> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> >> > >
> >> > >
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >> For additional commands, e-mail: dev-h...@cordova.apache.org
> >>
> >>
>


Re: Roadmap for next major versions

2018-07-02 Thread Niklas Merz
That sounds great. Please don't forget InAppBrowser. I worked in getting 
WKwebview running in InAppBrowser a while ago and I happy to help, review and 
test these changes . Dave Alden did a good pull request on this.

I flag like this sounds like a good way to test this in our app.

Am 3. Juli 2018, 06:39, um 06:39, Shazron  schrieb:
>I was thinking that the feature flag is just a convenience feature for
>setting/removing (depends on if the flag is set/omitted):
>
>in
>config.xml
>
>So something like this:
>`cordova platform add ios --wkwebview` or something to that effect.
>
>My thinking is -- this would make manual testing easier, and remove
>friction for testers in the interim, not to mention automated CI
>setups. If
>it's easier to test, perhaps more people would test it, at least that's
>what I hope...
>
>Yeah the custom scheme thing, since it's iOS 11, we might have to
>tackle
>that once we drop iOS 10 support I suppose.
>
>On Tue, Jul 3, 2018 at 12:27 PM Darryl Pogue 
>wrote:
>
>> Thanks Shazron!
>>
>> Regarding point 3 on your list, does that need to be a feature flag
>> since the WebView engine is already controlled via a preference in
>> config.xml? People should be able to opt-in that way just by adding a
>> preference, and then in a future release we just change the default
>> value for that preference, correct?
>>
>> From the Apple side, it sounds like they're very heavily encouraging
>> the use of custom schemes instead of file:/// URLs for apps serving
>> local files, but I think that wasn't introduced until iOS 11 which
>> might be an issue for us.
>>
>> On Mon, Jul 2, 2018 at 8:36 PM Shazron  wrote:
>> >
>> > Thanks Darryl,
>> > I'll be working on getting the WKWebView plugin up to snuff this
>week
>> (read
>> > the comment thread in your doc).
>> > 1. Review and resolve all existing PRs
>> > 2. Integrate the WKWebView plugin into the cordova-ios repo
>> > 3. Turn on WKWebView support via a feature flag (eventually this
>will be
>> > the default)
>> >
>> > I think no. 3 is a good way for interim testing versus having
>long-lived
>> > branches that might get out of sync. I don't think this will get
>into the
>> > same situation like `browserify` feature flag that was forgotten,
>since
>> we
>> > intend to bake this in for sure.
>> >
>> > [CDVWebViewEngineProtocol support](
>> >
>>
>https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/Public/CDVWebViewEngineProtocol.h
>> )
>> > so we can swap in any webview engine will remain unchanged.
>> >
>> > On Tue, Jun 26, 2018 at 12:43 PM Darryl Pogue 
>wrote:
>> >
>> > > Hi folks,
>> > >
>> > > As we've been discussing dropping node 4 support and how that
>requires
>> > > a major version bump, we should review what had already been on
>the
>> > > pile for next majors and what we want on the pile.
>> > >
>> > > I've started a Google Doc scratchpad to loosely organize
>high-level
>> > > goals for the various modules, and then we can start breaking
>them
>> > > down into JIRA tasks and putting them on the sprint boards:
>> > >
>> > >
>>
>https://docs.google.com/document/d/1P81YqXJbblIhzWWjWIE5AqjJvE29b1vHJX79TuIjyPM/edit#
>> > >
>> > > We know that iOS 12 and Android P are both likely coming in the
>fall,
>> > > so it might make sense to target our release to line up around
>that
>> > > time and make sure we support both of the new platform versions.
>I
>> > > don't love the idea of waiting that long, but let's be realistic
>about
>> > > what we can try to achieve.
>> > >
>> > > ~Darryl
>> > >
>> > >
>-
>> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> > > For additional commands, e-mail: dev-h...@cordova.apache.org
>> > >
>> > >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>


Re: Roadmap for next major versions

2018-07-02 Thread Shazron
I was thinking that the feature flag is just a convenience feature for
setting/removing (depends on if the flag is set/omitted):
 in
config.xml

So something like this:
`cordova platform add ios --wkwebview` or something to that effect.

My thinking is -- this would make manual testing easier, and remove
friction for testers in the interim, not to mention automated CI setups. If
it's easier to test, perhaps more people would test it, at least that's
what I hope...

Yeah the custom scheme thing, since it's iOS 11, we might have to tackle
that once we drop iOS 10 support I suppose.

On Tue, Jul 3, 2018 at 12:27 PM Darryl Pogue  wrote:

> Thanks Shazron!
>
> Regarding point 3 on your list, does that need to be a feature flag
> since the WebView engine is already controlled via a preference in
> config.xml? People should be able to opt-in that way just by adding a
> preference, and then in a future release we just change the default
> value for that preference, correct?
>
> From the Apple side, it sounds like they're very heavily encouraging
> the use of custom schemes instead of file:/// URLs for apps serving
> local files, but I think that wasn't introduced until iOS 11 which
> might be an issue for us.
>
> On Mon, Jul 2, 2018 at 8:36 PM Shazron  wrote:
> >
> > Thanks Darryl,
> > I'll be working on getting the WKWebView plugin up to snuff this week
> (read
> > the comment thread in your doc).
> > 1. Review and resolve all existing PRs
> > 2. Integrate the WKWebView plugin into the cordova-ios repo
> > 3. Turn on WKWebView support via a feature flag (eventually this will be
> > the default)
> >
> > I think no. 3 is a good way for interim testing versus having long-lived
> > branches that might get out of sync. I don't think this will get into the
> > same situation like `browserify` feature flag that was forgotten, since
> we
> > intend to bake this in for sure.
> >
> > [CDVWebViewEngineProtocol support](
> >
> https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/Public/CDVWebViewEngineProtocol.h
> )
> > so we can swap in any webview engine will remain unchanged.
> >
> > On Tue, Jun 26, 2018 at 12:43 PM Darryl Pogue  wrote:
> >
> > > Hi folks,
> > >
> > > As we've been discussing dropping node 4 support and how that requires
> > > a major version bump, we should review what had already been on the
> > > pile for next majors and what we want on the pile.
> > >
> > > I've started a Google Doc scratchpad to loosely organize high-level
> > > goals for the various modules, and then we can start breaking them
> > > down into JIRA tasks and putting them on the sprint boards:
> > >
> > >
> https://docs.google.com/document/d/1P81YqXJbblIhzWWjWIE5AqjJvE29b1vHJX79TuIjyPM/edit#
> > >
> > > We know that iOS 12 and Android P are both likely coming in the fall,
> > > so it might make sense to target our release to line up around that
> > > time and make sure we support both of the new platform versions. I
> > > don't love the idea of waiting that long, but let's be realistic about
> > > what we can try to achieve.
> > >
> > > ~Darryl
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>


Re: Roadmap for next major versions

2018-07-02 Thread Darryl Pogue
Thanks Shazron!

Regarding point 3 on your list, does that need to be a feature flag
since the WebView engine is already controlled via a preference in
config.xml? People should be able to opt-in that way just by adding a
preference, and then in a future release we just change the default
value for that preference, correct?

>From the Apple side, it sounds like they're very heavily encouraging
the use of custom schemes instead of file:/// URLs for apps serving
local files, but I think that wasn't introduced until iOS 11 which
might be an issue for us.

On Mon, Jul 2, 2018 at 8:36 PM Shazron  wrote:
>
> Thanks Darryl,
> I'll be working on getting the WKWebView plugin up to snuff this week (read
> the comment thread in your doc).
> 1. Review and resolve all existing PRs
> 2. Integrate the WKWebView plugin into the cordova-ios repo
> 3. Turn on WKWebView support via a feature flag (eventually this will be
> the default)
>
> I think no. 3 is a good way for interim testing versus having long-lived
> branches that might get out of sync. I don't think this will get into the
> same situation like `browserify` feature flag that was forgotten, since we
> intend to bake this in for sure.
>
> [CDVWebViewEngineProtocol support](
> https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/Public/CDVWebViewEngineProtocol.h)
> so we can swap in any webview engine will remain unchanged.
>
> On Tue, Jun 26, 2018 at 12:43 PM Darryl Pogue  wrote:
>
> > Hi folks,
> >
> > As we've been discussing dropping node 4 support and how that requires
> > a major version bump, we should review what had already been on the
> > pile for next majors and what we want on the pile.
> >
> > I've started a Google Doc scratchpad to loosely organize high-level
> > goals for the various modules, and then we can start breaking them
> > down into JIRA tasks and putting them on the sprint boards:
> >
> > https://docs.google.com/document/d/1P81YqXJbblIhzWWjWIE5AqjJvE29b1vHJX79TuIjyPM/edit#
> >
> > We know that iOS 12 and Android P are both likely coming in the fall,
> > so it might make sense to target our release to line up around that
> > time and make sure we support both of the new platform versions. I
> > don't love the idea of waiting that long, but let's be realistic about
> > what we can try to achieve.
> >
> > ~Darryl
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org



Re: Roadmap for next major versions

2018-07-02 Thread Shazron
Thanks Darryl,
I'll be working on getting the WKWebView plugin up to snuff this week (read
the comment thread in your doc).
1. Review and resolve all existing PRs
2. Integrate the WKWebView plugin into the cordova-ios repo
3. Turn on WKWebView support via a feature flag (eventually this will be
the default)

I think no. 3 is a good way for interim testing versus having long-lived
branches that might get out of sync. I don't think this will get into the
same situation like `browserify` feature flag that was forgotten, since we
intend to bake this in for sure.

[CDVWebViewEngineProtocol support](
https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/Public/CDVWebViewEngineProtocol.h)
so we can swap in any webview engine will remain unchanged.

On Tue, Jun 26, 2018 at 12:43 PM Darryl Pogue  wrote:

> Hi folks,
>
> As we've been discussing dropping node 4 support and how that requires
> a major version bump, we should review what had already been on the
> pile for next majors and what we want on the pile.
>
> I've started a Google Doc scratchpad to loosely organize high-level
> goals for the various modules, and then we can start breaking them
> down into JIRA tasks and putting them on the sprint boards:
>
> https://docs.google.com/document/d/1P81YqXJbblIhzWWjWIE5AqjJvE29b1vHJX79TuIjyPM/edit#
>
> We know that iOS 12 and Android P are both likely coming in the fall,
> so it might make sense to target our release to line up around that
> time and make sure we support both of the new platform versions. I
> don't love the idea of waiting that long, but let's be realistic about
> what we can try to achieve.
>
> ~Darryl
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>


Re: [VOTE] cordova-common@2.2.5 tools release (patch release)

2018-07-02 Thread Chris Brody
The vote has now closed. I would like to thank Jesse MacFadyen and
Shazron Abdullah for taking the time to review and vote. The results
are:

Positive Binding Votes: 3
- Jesse MacFadyen
- Shazron Abdullah
- Christopher Brody

Negative Binding Votes: 0

The vote has passed.
On Fri, Jun 29, 2018 at 10:37 PM Shazron  wrote:
>
> +1
>
> On Sat, Jun 30, 2018 at 10:23 AM Jesse  wrote:
>
> > I vote +1
> >
> > * [+] no known vulnerabilities found [440 packages audited]
> > * ran tests at tagged commit 2.2.5
> > * Ran coho audit-license-headers
> > * Ran coho check-license
> > * Ran coho verify-archive on release artifacts
> > * Ensured continuous build was green when repos were tagged
> >
> >
> >
> > @purplecabbage
> > risingj.com
> >
> > On Tue, Jun 26, 2018 at 6:57 PM, Chris Brody 
> > wrote:
> >
> > > Please review and vote on this cordova-common 2.2.5 (patch release) by
> > > replying to this email (and keep discussion on the [DISCUSS] thread)
> > >
> > > Release issue: https://issues.apache.org/jira/browse/CB-14174
> > >
> > > Purpose is to resolve npm audit issues without generating ugly engine
> > > warning messages on deprecated Node.js 4 version, as needed by
> > > cordova-android, cordova-ios, and additional tools and platform
> > > packages.
> > >
> > > Artifacts for this cordova-common patch release have been published
> > > to: https://dist.apache.org/repos/dist/dev/cordova/CB-14174/
> > >
> > > The package artifacts were published from their corresponding git tag(s):
> > >
> > > cordova-common: 2.2.5 (a77a1ed939)
> > >
> > > Upon a successful vote I will upload the archives to dist/, publish
> > > them to npm, and post the corresponding blog post.
> > >
> > > Voting guidelines:
> > >
> > https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
> > >
> > > Voting will go on for a minimum of 48 hours.
> > >
> > > I vote +1:
> > > * Ran coho audit-license-headers over the relevant repos
> > > * Ran coho check-license to ensure all dependencies and
> > > sub-dependencies have Apache-compatible licenses
> > > * Ensured continuous build was green when repos were tagged
> > >
> > > Thanks and best regards,
> > >
> > > Chris
> > >
> > > https://twitter.com/brodybits
> > >
> > > -
> > > 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