Re: Team page on Cordova website

[Jan Piotrowski]

There are existing tools that do what you suggest Raphael, mostly to
put contributors into READMEs of projects but I am sure that could be
abused to put it into a Markdown file that is included in the docs.

Apache also has a site that lists all PMC members etc (that I think
uses some AJAX + a JSON file), so one could probably easily build a
tool on top of that to regularly update a list for example.

-J

Am Do., 2. Apr. 2020 um 12:04 Uhr schrieb :
>
> I know I'm pretty late to the party here, but I wanted to voice my concerns
> regarding maintainability of such a list.
>
> My experience tells me that things that won't make a CI fail and yell at
> you will get outdated pretty quickly and don't receive much maintenance.
> Some of our packages have contributors lists in their package.json for
> example. However they are not current but rather a snapshot from an
> arbitrary point in time. Actually I wanted to open some PRs for removing
> them for some time, but there had always been other, more important things
> to get done.
>
> So how about, instead of maintaining a manual list that is bound to become
> outdated quickly, we try to leverage commit data from our repositories? I
> think of something like showing the most active committers of the last two
> years or something like that. Essentially a version of GitHub's
> Contributors[1] but aggregated over all our repos. I guess something like
> that should be achievable by using GitHub's API.
> 
>
> If this doesn't cover all bases we could still expand upon it: Add some
> static entries (e.g. PMC Chair), or show extended member profiles/bios in
> the dynamically generated list.
>
> I'm looking forward to your opinions. And thank you Niklas for the work you
> already put in.
>
> Cheers,
> Raphael
>
> [1]
> https://github.com/apache/cordova-lib/graphs/contributors?from=2018-04-02&to=2020-04-02&type=c
>
> Am Sa., 22. Feb. 2020 um 15:55 Uhr schrieb Niklas Merz <
> niklasm...@apache.org>:
>
> > Hi everyone,
> >
> > Like discussed before I think it might be a good idea to add a page to
> > our website for Cordova users to get to know the community members.
> >
> > I am writing here because to me this only makes sense if most of the
> > active committers are involved and want to be part of this list.
> >
> > I created this PR with the first draft and some screenshots:
> > https://github.com/apache/cordova-docs/pull/1063
> >
> > There are still some open points to do and discuss. I am not the best
> > web designer and would appreciate any help. Feel free to push to this
> > branch or create PRs any time.
> >
> > Looking forward to make this happen.
> >
> > Kind regards
> > Niklas
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >

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

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

[Jan Piotrowski]

I think in the past we also got pushback from INFRA on using bots via
apps because of access to data etc (similar to CI services etc). Not
sure if that changed in the last few months.

J

Am Fr., 17. Apr. 2020 um 13:44 Uhr schrieb Niklas Merz :
>
> I think I have to agree there.
>
> I would vote -0 for stale locking. This is really a mixed bag. As a user this 
> annoyed me in some projects that issues are closed and locked but  are 
> discussing exactly my problem. Marking as stale or wontfix should be a good 
> idea. But locking them could be a manual step? Locking should avoid spammy 
> responses and not turn users away from giving feedback when maintainers don't 
> triage for some time.
>
> +1 for closing old issues and asking for response automatically and the other 
> tags. I like that the times in the PRs are quite long.
>
>
> April 17, 2020 1:04 PM, "julio cesar sanchez"  wrote:
>
> > I'm -1 for the stale bot, I've seen in other repos and it just ends closing
> > valid issues and PRs because the maintainers didn't have time to look into
> > them, but that's maintainers "fault" and I think it "punish" users.
> >
> > I'm +1 for the other ones.
> >
> > El vie., 17 abr. 2020 a las 12:43, Bryan Ellis ()
> > escribió:
> >
> >> I forgot to link PR:
> >>
> >> https://github.com/apache/cordova/pull/210
> >>
> >> This PR contains the configurations for the apps described previously.
> >>
> >> On Fri, Apr 17, 2020 at 7:42 PM Bryan Ellis  wrote:
> >>
> >> I would like to better improve our GitHub issue tracker by adding some of
> >> the Probot apps that can be installed to GitHub.
> >>
> >> There are many available apps and I wanted to start off with a selected
> >> few that would help mitigate some of the tedious tasks.
> >>
> >> The apps I would like to bring up in this discussion and to vote on are:
> >>
> >> - Stale
> >> - Request Info
> >> - Lock Threads
> >> - No Response
> >>
> >> The "*Stale*" app is used to automatically close issues and prs which
> >> have no activity over a period of time. This app provides a lot of
> >> configuration flexibility. We can warn users after x number of days that
> >> the issue/pr has become stale and append a stale label. After x number of
> >> days being stale, then the app will close the issue/pr. We can ensure
> >> that
> >> the issues and prs are not closed immediately and provide users ample
> >> time
> >> to reply back.
> >>
> >> The "*Request Info*" app is used to automatically alert users when they
> >> have created a new issue or pr that does not have any description. The
> >> app
> >> will inform them that they will need to provide information for use to be
> >> able to help them. One of the great things about this app is that it can
> >> also check against our templates. If a user has submitted an issue or pr
> >> with only the default template, it will also fail the check.
> >>
> >> The "*No Response*" app is used to automatically close issues that have
> >> not received a response from the author. This app pairs nicely with the
> >> "request-info" app which manages the warning and label pinning. This app,
> >> on the other hand, does not support PRs as the "request-info" also
> >> supports. This means we will need to manually manage PRs in the meantime
> >> while we wait for the app to be updated.
> >>
> >> The "*Lock Threads*" app is used to lock the threads of closed issues or
> >> prs after (x) number of days of inactivity. This is to help prevent
> >> long-lived issues and prs after being resolved and closed. If a user
> >> still
> >> has issues to report after the thread of an issue or PR is locked, they
> >> should create a new issue. The locking of the thread does not occur
> >> immediately after an issue or PR is closed. Users can still have an
> >> opportunity to communicate if they feel the issue was closed prematurely.
> >>
> >> Here is an example of PR to configure and use the bots. Obviously, I
> >> would
> >> also need to enable the bot on each repo.
> >>
> >> Please let me know what is your thoughts on this and even make a vote on
> >> it. I would like to move forward and start using the power of the apps
> >> that
> >> can be installed.
> >>
> >> Here is the general process based on the configurations in the PR.
> >>
> >> *For proper Issues & PRs*
> >>
> >> - After 2 months of no activity, the issue/pr will become stale and
> >> the thread will be warned. A "stale" label is appended.
> >> - After 2 weeks of being stale, and continues to have no activity, the
> >> issue/pr is closed.
> >> - After 2 weeks of being closed, and continues to have no activity,
> >> the issue/pr thread will become locked.
> >>
> >> In total, this process covers ~3 months. (88 days exactly). After being
> >> flagged stale, users have still enough time to create an activity to
> >> prevent the app from closing and locking the thread.
> >>
> >> Additionally, I have also declared labels of "security" and "pinned" to
> >> be
> >> ignored by the app so it will never go s

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

[Jan Piotrowski]

+1

Am Di., 18. Aug. 2020 um 08:46 Uhr schrieb Dave Alden <
d...@workingedge.co.uk>:

> +1
>
> On Tue, 18 Aug 2020, 05:47 Bryan Ellis,  wrote:
>
> > This vote is only for the purpose of unarchive and remove the deprecation
> > status for the plugin of:
> >
> >   cordova-plugin-device-orientation
> >
> > Please keep the discussion in the discussion thread.
> >
> > Vote will follow the usual voting rules:
> > * Minimum of 48 Hours
> > * 2 + 1 Binding Vote
> >
> > +1
>

Re: [VOTE] Unarchive & Un-deprecate cordova-plugin-device-motion

[Jan Piotrowski]

+1

Am Di., 18. Aug. 2020 um 06:59 Uhr schrieb Norman Breau <
nor...@normanbreau.com>:

> 1+
>
> Norman Breau
> Software Developer
>
> nor...@normanbreau.com (
> https://link.getmailspring.com/link/26afd337-8d43-4f5e-9b5d-b565ffb5f...@getmailspring.com/0?redirect=mailto%3Anorman%40normanbreau.com&recipient=ZGV2QGNvcmRvdmEuYXBhY2hlLm9yZw%3D%3D
> )
> https://breautek.com (
> https://link.getmailspring.com/link/26afd337-8d43-4f5e-9b5d-b565ffb5f...@getmailspring.com/2?redirect=https%3A%2F%2Fbreautek.com&recipient=ZGV2QGNvcmRvdmEuYXBhY2hlLm9yZw%3D%3D
> )
>
> On Aug 18 2020, at 1:47 am, Bryan Ellis  wrote:
> > This vote is only for the purpose of unarchive and remove the
> deprecation status for the plugin of:
> >
> > cordova-plugin-device-motion
> > Please keep the discussion in the discussion thread.
> > Vote will follow the usual voting rules:
> > * Minimum of 48 Hours
> > * 2 + 1 Binding Vote
> >
> > +1
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
>

Re: [VOTE] Unarchive & Un-deprecate cordova-plugin-file-transfer

[Jan Piotrowski]

+1

Am Di., 18. Aug. 2020 um 08:31 Uhr schrieb Tim Brust :

> +1
>
> Sent from my iPhone
>
> > On 18. Aug 2020, at 8:22 AM, Dave Alden  wrote:
> >
> > +1
> >
> >> On Tue, 18 Aug 2020, 05:47 Bryan Ellis,  wrote:
> >>
> >> This vote is only for the purpose of unarchive and remove the
> deprecation
> >> status for the plugin of:
> >>
> >>  cordova-plugin-file-transfer
> >>
> >> Please keep the discussion in the discussion thread.
> >>
> >> Vote will follow the usual voting rules:
> >> * Minimum of 48 Hours
> >> * 2 + 1 Binding Vote
> >>
> >> +1
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >> For additional commands, e-mail: dev-h...@cordova.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: 💡Cordova as a monorepo - ??

[Jan Piotrowski]

> and it would help us to keep the issues and discussions all in one place.

I would challenge you actually want that. To be able to properly work on
one plugin, you would need to have labelled all issues and PRs and then
filter all views for that.

In my experience this only makes sense for closely related and connected
codebases (as the core, but definitely not plugins).

J

Am Fr., 28. Aug. 2020 um 15:50 Uhr schrieb Norman Breau <
nor...@normanbreau.com>:

> I think Erisu was planning on making nightly releases for plugins, but I
> generally agree. I think Monorepo may make more sense for the core, but not
> for the entire code base.
>
> And I think the point that mono repos make it hard to install from github
> is a very good point to make.

Re: Migrate Sauce Labs user used in CI testing from snay to cordova

[Jan Piotrowski]

You might go slow on this - somewhere in the back of my head I have
_something_ why we did not follow through with this in the past but I can
not figure out what it was, sorry :/ Hopefully it is nothing and will just
work.

J



Am So., 30. Aug. 2020 um 19:55 Uhr schrieb Tim Brust :

> Hi there,
>
> I'd like to continue to migrate our testing setup from TravisCI to GitHub
> Actions. Currently, our plugins are all running on Travis and test against
> VMs on Sauce Labs [1] and are not yet migrated.
>
> They currently use the Travis-encrypted credentials of Alexander ("snay").
> Since I do not have those credentials, I can't open an INFRA ticket to add
> the access key as a secret to GH Actions.
>
> Luckily, Jan created a user called "cordova" which seems more fitting than
> a personal/private user account, too. Also, the credentials are properly
> checked into our SVN and could be used for manual testing of specific
> device combos. The accounts should be identical as Sauce Labs offers 5 VMs
> for open source users for free.
>
> Therefore, I'd like to switch all our Sauce Labs tests to the cordova
> account when I start (try) the migration to GH actions for the remaining
> repos. As you all know, no ETAs on these tasks :)
>
> Let me know what you think. Ideally I'd like to omit the discussion if
> Sauce Labs is needed at all in this thread.
>
> Best,
> Tim
>
> [1] - https://app.saucelabs.com/open_sauce/user/snay/tests
> --
> Tim Brust
>

Re: [DISCUSS] Moving JIRA issues to Github

[Jan Piotrowski]

If people post their issue at the wrong repo (which of course can and
will happen from time to time), there is a way to move them over with
minimal loss of information:

https://github.com/ionic-team/ionic/issues/12542
https://github.com/ionic-team/ionic-cli/issues/2597

This works for issues where several people replied already in the
exact same way:

https://github.com/ionic-team/ionic/issues/11898
https://github.com/ionic-team/ionic-cli/issues/2386

As the original poster of the issue and each reply is @-mentioned they
are notified about the "new" issue and can continue participating.
Replying users also can just include the @username in their new
replies again to make sure people get notified.

-J



2017-08-02 21:53 GMT+02:00 Filip Maj :
> I think the ease of use of GitHub issues overcomes potential problems
> about cross-referencing issues. Worth noting on this topic that GitHub
> already provides good support for referencing pull requests from
> issues across repos / orgs.
>
> The benefit of having issues and PRs in one place, to me, is a benefit
> too tasty to pass up.
>
> Darryl, do you have examples of issues that you think could be
> problematic in a GitHub-based world?
>
> On Wed, Aug 2, 2017 at 12:43 PM, Darryl Pogue  wrote:
>> My concern with GitHub issues is that we have a tonne of repos and issues
>> can easily span across them, and we'd lose the one central place for issue
>> tracking and triage. I worry that we'd be inundated with issues on the
>> wrong repos, or without additional information, and triaging would become
>> an insurmountable chore leading to a worse backlog than we already have in
>> JIRA.
>>
>> On 2 August 2017 at 12:38, Shazron  wrote:
>>
>>> Phase 1 of our move to Github is complete, see:
>>> https://issues.apache.org/jira/browse/INFRA-14347
>>>
>>> We need a migration plan for moving JIRA issues to Github Issues before we
>>> enable Github Issues on those repos.
>>>
>>> Once we figure those out, we can proceed with Phase 2:
>>> https://issues.apache.org/jira/browse/INFRA-14398
>>>
>>> I'll start it off by saying that ideally we:
>>> 1. Triage issues
>>> 2. Automate migration of existing open issues to Github issues
>>> 3. "Close off" the JIRA issues
>>>
>>> The impact of this is, the original reporters will not get notified of
>>> further updates to the issue except for a link to the new issue on Github
>>> as a JIRA comment (since they will not be subscribed to the Github issue).
>>>
>>> We could also migrate every open issue first, then triage later in Github,
>>> as well.
>>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Re: [DISCUSS] Moving JIRA issues to Github

[Jan Piotrowski]

>> As a user, I’ll occasionally skim the recently opened bugs in Jira across 
>> the entire project to see if any may affect us. Is there going to be a way 
>> to do this with Github? Subscribing to notifications could be a work-around 
>> but it’s not ideal.
>
> Good question. I can't really think of a way to do this...

Github doesn't offer this out of the box (besides watching all repos
yourself, which comes with its own challenges). But Github has an API,
I am pretty sure someone already wrote something that combines issues
of several repos into one interface to look at, then links to the
individual issues (If not, it wouldn't be too much work to create
something like that) (Could become the new issues.cordova.io maybe?).
Would this fulfill your use case?

-J

2017-08-03 3:13 GMT+02:00 Filip Maj :
>> Since it looks like not all repositories will be migrated where should their 
>> issues go?
>
> All repositories will be migrated.
>
>> What about issues for repositories that don’t yet exist
>
> Can you give me an example?
>
>> or cross-cutting issues?
>
> I think if you absolutely need issues related to multiple repos, you
> can always create multiple issues in all relevant repos and
> cross-reference them.
>
>> As a user, I’ll occasionally skim the recently opened bugs in Jira across 
>> the entire project to see if any may affect us. Is there going to be a way 
>> to do this with Github? Subscribing to notifications could be a work-around 
>> but it’s not ideal.
>
> Good question. I can't really think of a way to do this...
>
>> Are we going to get more high quality bug reports using Github? This may not 
>> be answerable without trying it out, but making issues easier to create 
>> issues could cause an influx of questions and non-cordova related bugs. This 
>> could add on to the difficulties of triaging and migrating bugs across repos.
>
> To be fair, we already get painful triage-work via GitHub just by
> opening up Pull Requests to the public. People will use those to post
> questions or issues, because they are unaware that there are other
> support and issue filing avenues (they will mask them as PRs merging a
> release branch into master). At least those people now have a more
> obvious place to file issues: the Issues section on GitHub. We already
> have a lot of triage work on JIRA as it is. I doubt this will go down.
> That said, I don't think that's necessarily bad. Will we have more
> work? Probably. Will we be able to more easily identify issues, and
> earlier, and generally be also more accessible to our community? I
> would think yes. Double-edged sword. I say let's see how it goes.
>
>> If we migrate before triaging where will all the un-triaged issues end up?
>
> They would end up in GitHub, at which point we'd triage them within GitHub.
>
>> Also if we enable Github issues before phase 2 are we going to be using both 
>> Jira and Github Issues for a period of time?
>
> Yes.
>
> Different topic: Shaz, based on your INFRA ticket / phase breakdown,
> the implication is that there will be leftover cordova repos in Apache
> Git (cordova-medic, weinre, deprecated platforms / plugins). What do
> we do with those? Separate discussion?
>
> On Wed, Aug 2, 2017 at 5:32 PM, Connor Pearson  wrote:
>> I have a few questions about moving issues to GitHub. I haven’t used Github
>> issues much so these all may be easily solvable.
>>
>> * Since it looks like not all repositories will be migrated where should
>> their issues go? What about issues for repositories that don’t yet exist or
>> cross-cutting issues?
>> * As a user, I’ll occasionally skim the recently opened bugs in Jira across
>> the entire project to see if any may affect us. Is there going to be a way
>> to do this with Github? Subscribing to notifications could be a work-around
>> but it’s not ideal.
>> * Are we going to get more high quality bug reports using Github? This may
>> not be answerable without trying it out, but making issues easier to create
>> issues could cause an influx of questions and non-cordova related bugs.
>> This could add on to the difficulties of triaging and migrating bugs across
>> repos.
>> * If we migrate before triaging where will all the un-triaged issues end
>> up? Also if we enable Github issues before phase 2 are we going to be using
>> both Jira and Github Issues for a period of time?
>>
>> -Connor
>>
>>
>> On August 2, 2017 at 7:08:18 PM, Jan Piotrowski (piotrow...@gmail.com)
>> wrote:
>>
>> If people post their issue at the wrong repo (which of course can and
>> will 

Re: [DISCUSS] Moving JIRA issues to Github

[Jan Piotrowski]

> What about security issues?
> Right now on jira we have private security issues not visible for the regular 
> people and as far as I know, we can't do that on GitHub

Initial idea: Have an email address where people can send messages to,
the recipient then creates an issue on a private Github repo for
further talking about it.
You could probably also create a public form that does the same job of
the email address and person creating the ticket automatically if too
much effort and needed too often.
(But maybe there is a better solution, one could investigate how other
Github based projects do that)

-J

2017-08-03 11:55 GMT+02:00 julio cesar sanchez :
> What about security issues?
>
> El 3 ago. 2017 4:53 a. m., "Jan Piotrowski"  escribió:
>
>> >> As a user, I’ll occasionally skim the recently opened bugs in Jira
>> across the entire project to see if any may affect us. Is there going to be
>> a way to do this with Github? Subscribing to notifications could be a
>> work-around but it’s not ideal.
>> >
>> > Good question. I can't really think of a way to do this...
>>
>> Github doesn't offer this out of the box (besides watching all repos
>> yourself, which comes with its own challenges). But Github has an API,
>> I am pretty sure someone already wrote something that combines issues
>> of several repos into one interface to look at, then links to the
>> individual issues (If not, it wouldn't be too much work to create
>> something like that) (Could become the new issues.cordova.io maybe?).
>> Would this fulfill your use case?
>>
>> -J
>>
>> 2017-08-03 3:13 GMT+02:00 Filip Maj :
>> >> Since it looks like not all repositories will be migrated where should
>> their issues go?
>> >
>> > All repositories will be migrated.
>> >
>> >> What about issues for repositories that don’t yet exist
>> >
>> > Can you give me an example?
>> >
>> >> or cross-cutting issues?
>> >
>> > I think if you absolutely need issues related to multiple repos, you
>> > can always create multiple issues in all relevant repos and
>> > cross-reference them.
>> >
>> >> As a user, I’ll occasionally skim the recently opened bugs in Jira
>> across the entire project to see if any may affect us. Is there going to be
>> a way to do this with Github? Subscribing to notifications could be a
>> work-around but it’s not ideal.
>> >
>> > Good question. I can't really think of a way to do this...
>> >
>> >> Are we going to get more high quality bug reports using Github? This
>> may not be answerable without trying it out, but making issues easier to
>> create issues could cause an influx of questions and non-cordova related
>> bugs. This could add on to the difficulties of triaging and migrating bugs
>> across repos.
>> >
>> > To be fair, we already get painful triage-work via GitHub just by
>> > opening up Pull Requests to the public. People will use those to post
>> > questions or issues, because they are unaware that there are other
>> > support and issue filing avenues (they will mask them as PRs merging a
>> > release branch into master). At least those people now have a more
>> > obvious place to file issues: the Issues section on GitHub. We already
>> > have a lot of triage work on JIRA as it is. I doubt this will go down.
>> > That said, I don't think that's necessarily bad. Will we have more
>> > work? Probably. Will we be able to more easily identify issues, and
>> > earlier, and generally be also more accessible to our community? I
>> > would think yes. Double-edged sword. I say let's see how it goes.
>> >
>> >> If we migrate before triaging where will all the un-triaged issues end
>> up?
>> >
>> > They would end up in GitHub, at which point we'd triage them within
>> GitHub.
>> >
>> >> Also if we enable Github issues before phase 2 are we going to be using
>> both Jira and Github Issues for a period of time?
>> >
>> > Yes.
>> >
>> > Different topic: Shaz, based on your INFRA ticket / phase breakdown,
>> > the implication is that there will be leftover cordova repos in Apache
>> > Git (cordova-medic, weinre, deprecated platforms / plugins). What do
>> > we do with those? Separate discussion?
>> >
>> > On Wed, Aug 2, 2017 at 5:32 PM, Connor Pearson  wrote:
>> >> I have a few questions about moving issues to GitHub. I haven’t used
>> Github

Re: github update

[Jan Piotrowski]

Off-list:
Why do the repos have to be moved to the apache org? Having a cordova
org would have been a much better central place to group all and
highlight the important repos and what is going on.

-J

2017-08-17 20:34 GMT+02:00 Steven Gill :
> So we have officially moved 4 repos under apache org from cordova org [1].
>
> https://github.com/apache/cordova-new-committer-and-pmc
> https://github.com/apache/cordova-status
> https://github.com/apache/cordova-apache-board-reports
> https://github.com/apache/cordova-discuss
>
> These four repos will function the same way as they did under cordova org.
> Issues with repo, issue and pr labeling, ability to merge from github
> interface.
>
> We are still working towards moving issues from JIRA into their individual
> repos. You can view the discussion at [2]
>
> We have only moved over platform repos to github/gitbox proper so far. We
> are waiting on Infra for next few repos. [3]
>
> Lastly, commits and PR notifications for our new full github repos won't be
> coming to the dev list anymore. They are going to comm...@cordova.apache.org.
> You can subscribe to that list or hit watch on repos you are interested in
> via the github interface (this is what I do)
>
> [1] https://issues.apache.org/jira/browse/INFRA-14815
> [2] https://github.com/apache/cordova-discuss/pull/75
> [3] https://issues.apache.org/jira/browse/INFRA-14398

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

Re: [DISCUSS] [Play Services Version]

[Jan Piotrowski]

Is this the same problem that (allegedly) can be fixed by using this plugin?
https://github.com/dpa99c/cordova-android-support-gradle-release

2017-08-18 18:02 GMT+02:00 julio cesar sanchez :
> This problem is not only present on Play Services version, any other
> library or framework, from Android (like support libraries) or any 3rd
> party.
> For 3rd party is less common, but for support libraries is very common to
> have this kind of problem.
>
> I have had another idea that I think should be simpler, but will be a big
> breaking change.
>
> What if we drop support for the framework tag in plugin xml and move the
> functionality to config.xml?
>
> Plugin authors should use config-file tag to add the framework on the
> config.xml, something like
> 
> 
> 
>
>
> The problem is that any plugin using a framework will need an update, while
> the other proposed approach will only need to update conflicting plugins.
>
>
> And if the config.xml already includes a com.android.support:support-v4
> then ignore it.
>
> El 8 ago. 2017 3:03 p. m., "Audrey So"  escribió:
>
>> Hi all!
>>
>>
>> There is a proposal to offer an alternative solution for CB-13145:
>> https://issues.apache.org/jira/browse/CB-13145.
>>
>> Please review the proposal below:
>>
>> https://github.com/cordova/cordova-discuss/pull/74/files
>>
>>
>> We would appreciate any feedback, advice, comments, and questions you have
>> on this proposal. Looking forward to hearing any thoughts. Thanks so much!
>>
>>
>> Audrey
>>

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

Re: [DISCUSS] cordova-ios 4.1.1 Release

[Jan Piotrowski]

... like all Ionic projects for example:
https://github.com/ionic-team/ionic2-app-base/blob/master/config.xml#L87

Will this trip these up somehow?

-J

2017-08-31 23:44 GMT+02:00 Filip Maj :
> By the way, I think we should include notes about
> cordova-plugin-console being integrated in the blog post /
> announcement for this release - that may trip up folks trying to
> update cordova-ios, if they had the console plugin manually installed
> already.
>
> On Thu, Aug 31, 2017 at 7:21 PM, Shazron  wrote:
>> Stalled on testing and fixing https://github.com/apache/cordova-ios/pull/335
>> before a release can be sent for vote
>>
>> On Thu, Aug 24, 2017 at 4:12 PM, Shazron  wrote:
>>
>>> Issues on the board have been completed, the PRs need review:
>>>
>>> Board:
>>> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=173
>>>
>>> Pull requests:
>>> 1. https://github.com/apache/cordova-ios/pull/326
>>> 2. https://github.com/apache/cordova-ios/pull/331
>>> 3. https://github.com/apache/cordova-ios/pull/332
>>>
>>>
>>> On Tue, Aug 22, 2017 at 6:00 PM, Shazron  wrote:
>>>
 Renamed board to 4.5.0, left Fil's issue and another that has a PR that
 is almost done review:
 https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=173

 On Tue, Aug 22, 2017 at 11:47 AM, Shazron  wrote:

> I'll get that in as the lone issue on the board.
> I'm also thinking this should be 4.5.0 instead of 4.4.1 because there is
> a new feature in there.
>
> On Tue, Aug 22, 2017 at 9:20 AM, Filip Maj  wrote:
>
>> CB-12830 [1] is something that I think we should sneak in to the
>> release, time permitting.
>>
>> [1] https://issues.apache.org/jira/browse/CB-12830
>>
>> On Sat, Aug 12, 2017 at 4:05 AM, Shazron  wrote:
>> > 😂 I do! yes 4.4.1
>> >
>> > On Aug 11, 2017 at 5:40 PM, julio cesar sanchez <
>> jcesarmob...@gmail.com>
>> > wrote:
>> >
>> >
>> > You probably mean 4.4.1
>> >
>> > El 11 ago. 2017 3:37 p. m., "Steven Gill" 
>> escribió:
>> >
>> > Yay!
>> >
>> > On Aug 11, 2017 12:19 PM, "Shazron"  wrote:
>> >
>> > Long overdue.
>> >
>> > The board is here:
>> > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=173
>> >
>> > Any issues in the left column that absolutely need to go in? If not I
>> >
>> > will
>> >
>> > punt them to the next release.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>
>

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

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

Re: [DISCUSS][DOCS] Revert a change

[Jan Piotrowski]

I am actually surprised deploying is a manual process at all.
Having read the steps, I understand why of course.

As a person that jumps in on all kinds of projects, I absolutely
prefer docs that list each and every little step needed (including all
the `cd` etc).

The need for manual steps or checks could be emphasized by using a
numbered list or checklist for the individual steps.

(Will this stay on SVN even after the repo switch to Github? Merging
and `gh-pages` is so nice and simple)

-J

2017-09-13 9:02 GMT+02:00 Shazron :
> This relates solely to instructions on how to *build* the site, and not the
> contents of the site itself.
>
> Bringing this up here for discussion since a committer wants to revert a
> change by another committer, and there is potential for disagreement.
>
> The pull request to revert is here:
> https://github.com/apache/cordova-docs/pull/729
>
> There has been discussion on the original change here:
> https://github.com/apache/cordova-docs/commit/96c5ab0f98c0b62160661dcd9a9db5549fe43f94
>
> Two issues here:
> 1. The change from `gulp build --prod` to `npm run serve`
> 2. This instruction here (not reverted in the PR):
> https://github.com/apache/cordova-docs/commit/d61f3ddc84dac4b013c0607230b9cf10921a416b
>
> Issue (1) has some discussion in the GH link above for the original change.
>
> Issue (2) there was some discussion in the Cordova Slack, that the reason
> the `svn commit` wasn't there in the first place is to prevent copy/paste
> of the commands without going through the changes step by step since
> deploying to a site is an expensive operation that can screw up the site if
> proper care was not done.
>
> My reason for adding the command was that the instructions are not complete
> (when I had to do it myself when updating the docs for cordova-ios
> release). I understand the rationale, but the instructions seem incomplete
> (especially for new committers that haven't heard of SVN, I know they can
> Google it, but that's more friction) and my other reason is: we should
> trust that committers will do the right thing.
>
> Not to make a mountain out of a mole-hill but it's important that these
> revert discussions be out in the open so as misunderstandings/hurt feelings
> don't occur, and we can nip it in the bud.
>
> Thoughts from the community?

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

Re: [proposal] Remove tool generated docs from camera plugin?

[Jan Piotrowski]

The "not aware" problem can probably be resolved (80/20) by adding
comments to the template that are also in the generated output.

But it the TEMPLATE.md actually a good idea? Is it worth the extra effort?

-J

2017-10-15 0:01 GMT+02:00 julio cesar sanchez :
> cordova-plugin-camera docs work on a different way than other plugins. The
> README.md is generated from jsdoc2md/TEMPLATE.md when the commit is done.
> I think it was a proof of concept to be done in all the plugins, but it the
> end it was only done in camera plugin.
> The problem is most people is not aware of this, so they just update the
> README.md manually as on any other plugins, and most of the committers
> aren't aware neither or forgot about it and just merge those changes.
>
> So, I was about to send a new PR and the jsdoc2md/TEMPLATE.md is out of
> sync with the README.md.
>
> So, we have two options, we can move back to a regular README.md like the
> other plugins, or do this in all the plugins and not accept README.md file
> changes without the corresponding jsdoc2md/TEMPLATE.md.
>
> What do you think?

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

Re: PR to add native-scroll-to-top option to cordova-plugin-statusbar

[Jan Piotrowski]

Sounds like a useful change.

-J

2017-10-20 19:22 GMT+02:00 julio cesar sanchez :
> Any other opinions about this?
>
>
>
> 2017-10-01 15:56 GMT+02:00 julio cesar sanchez :
>
>> I'm +1 on this
>>
>> 2017-09-30 0:56 GMT+02:00 Lu Wang :
>>
>>> This is in regards to the following PR: https://github.com/apache/cord
>>> ova-plugin-statusbar/pull/83 >> dova-plugin-statusbar/pull/83>
>>>
>>> I was told by @jcesarmobile that it’s best if I email the dev mailing
>>> list.
>>>
>>> There’s currently a bug filed as https://issues.apache.org/jira
>>> /browse/CB-13124  where
>>> in the statusTap event is delayed until momentum scrolling is complete.
>>> This means that if you’re using custom scroll-to-top behavior written in
>>> JavaScript, it will not fire until all momentum scrolling has stopped. This
>>> can cause the UI to look sluggish. Instructions for reproducing the bug are
>>> within the filed Jira Issue.
>>>
>>> I’m proposing in the PR that we add an option to allow the native status
>>> bar tap behavior. This way, the scroll-to-top is processed by the native
>>> app and not processed in JavaScript where it has to wait for the statusTap
>>> event to fire.
>>>
>>> Let me know if there are any questions.
>>>
>>> — Lu
>>
>>
>>

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

Re: Small UI Bug

[Jan Piotrowski]

Hm, am I correct to assume that your initial email included a
screenshot of a visual problem? Seems the mailing list filters these
out.

I reported a bug some time ago that could match the description in your email:
https://issues.apache.org/jira/browse/CB-13402

2017-10-23 11:53 GMT+02:00 Sridhar Yadav :
> PFA small UI bug.
>
> Gap for "Cordova App Showcase" section
>
>
> Regards,
> Sridhar
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org

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

Re: [DISCUSS] Cordova-Android 6.4.0 Release

[Jan Piotrowski]

Yep, PR for it is here: https://github.com/apache/cordova-docs/pull/757

2017-11-13 19:07 GMT+01:00 julio cesar sanchez :
> Are we having a blog post about it?
>
> 2017-11-01 22:39 GMT+01:00 julio cesar sanchez :
>
>> +1
>>
>> El 1 nov. 2017 6:48 p. m., "Steven Gill" 
>> escribió:
>>
>>> Do it!
>>>
>>> On Wed, Nov 1, 2017 at 10:28 AM, Joe Bowser  wrote:
>>>
>>> > 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?
>>> >
>>>
>>

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

Re: [DISCUSS] Cordova-iOS 4.5.4 Release

[Jan Piotrowski]

>From Slack:

> michaelbschmidt [9:30 AM]
> @surajpindoria for the upcoming cordova-ios release 4.5.4: please merge the 
> pull request on CB-13523 - this is needed for releasing in Xcode 9 in some 
> circumstances
> https://github.com/apache/cordova-ios/pull/347

https://cordova.slack.com/archives/C068FK885/p151064821514



2017-11-13 23:14 GMT+01:00 Suraj Pindoria :
> This release fixes an issue related to iPhone X launch storyboard
> constraints as well as a minor fix that removes an error when compiling
> down to Objective-C code. Is anyone of aware of anything else that we
> should try to get in for this release?
>
> If not, I will continue with the release tomorrow.

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

Re: Cordova-plugin-screen-orientation on iOS

[Jan Piotrowski]

Hey Dan,

I don't know enough Obj-C to review this, but this sounds like a
_really_ useful feature and change. Hope someone else can review this,
so it can become part of the plugin.

Thanks for the great work!

-J



2017-11-25 2:27 GMT+01:00 Dan Field :
> Hi all,
>
> I've submitted a pull request here: https://github.com/
> apache/cordova-plugin-screen-orientation/pull/24#event-1357350620 (jira
> issue here: https://issues.apache.org/jira/browse/CB-13405) related to the
> iOS behavior of this plugin.  The basic issue is that when the screen is
> locked and then unlocked in iOS, it doesn't automatically return to the
> orientation the user had before locking.  It will respond if the user
> manually turns the device a few times, but it can result in the orientation
> getting "stuck" in the locked position temporarily until the user starts
> turning the device.
>
> My solution is to record the position the phone is in before locking and
> attempt to set the orientation back to that initial position.  This has
> resulted in a better use experience in our testing for the production app I
> work on.  I'm doing this in the iOS specific code because the same issue
> doesn't occur on Android (at least on versions that I've tested, 6.x and
> 7.x).
>
> I'd welcome any comments/reviews/feedback!
>
> Thanks,
>
> Dan

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

Re: Regarding pull request CB-13409 in cordova-plugin-inappbrowser

[Jan Piotrowski]

Hi Steinar,

the changes from the PR sound pretty useful to me.

I don't know enough Obj-C to review your actual code, but I hope
someone else can do that and get your code merged.

Thanks for the work!

-J

Ps: "will someone officially review this or what?" is not the most
appropriate language. We are all volunteers here, so asking nicely for
input and a review is generally the better solution.

2017-11-23 13:46 GMT+01:00 Steinar Á. Steinarsson
:
> Hi,
>
> This pull request adds a few customization options for inappbrowser's 
> toolbar, both for iOS and Android. A description and some screenshots can be 
> found here: https://issues.apache.org/jira/browse/CB-13409 . Also, a 
> discussion about this PR can also be found here: 
> https://github.com/apache/cordova-plugin-inappbrowser/pull/246
> So will someone officially review this or what ?
>
> Regards,
>
> Steinar Ágúst
>
> Fyrirvari/Disclaimer: http://www.landsbankinn.is/disclaimer

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

Re: [DISCUSS] Cordova-Android 7.0.0

[Jan Piotrowski]

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 :
> 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

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

Re: [DISCUSS] Cordova-Android 7.0.0

[Jan Piotrowski]

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 :
> 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  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 :
>> > 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
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Re: [DISCUSS] Cordova-Android 7.0.0

[Jan Piotrowski]

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.

-J


2017-11-29 0:03 GMT+01:00 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 
> 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 :
>> > 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 
>> 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 :
>> >> > 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
>> Cross

Re: [DISCUSS] Cordova-Android 7.0.0

[Jan Piotrowski]

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 :
> 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  wrote:
>> On Tue, Nov 28, 2017 at 3:35 PM, Jan Piotrowski 
>> 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 :
>>> > 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.
>>> >
>>> >

Re: Transparent Splash Screen Background - Windows 10

[Jan Piotrowski]

Sounds like a very useful change that will improve Cordova apps on Windows.
+1

2018-01-11 11:56 GMT+01:00 Terence M. Bandoian :
> Julio suggested I bring this up for discussion so... related to:
>
> CB-13641 - https://issues.apache.org/jira/browse/CB-13641
> and https://github.com/apache/cordova-windows/pull/245
>
> I'd like to find out if there is any support for or objections to allowing
> transparent splash screen backgrounds on Windows.
>
> As you know, Cordova apps targeting Windows 10 execute on desktops and
> laptops in addition to tablets.  In that environment, some apps - the
> Settings app, for example - use the user-selected accent color for the
> splash background as well as the title bar background. Following that
> convention in some cases results in a more aesthetically pleasing startup
> than with a fixed color.  And, using 'transparent' as the splash background
> color value causes exactly that to take place.
>
> In the current splash screen implementation for Windows, both the title bar
> background and the window background are filled with the splash background
> color at startup.  Then, when the splash page is hidden, the title bar
> reverts to the user-selected accent color and the window to the app
> background which, depending on the colors in use, may not be a very
> appealing transition.
>
> In my case, I found using the accent color as the background much more
> satisfying which is why I went ahead and created the PR.  Other developers
> may find it useful as well.  And for those that don't, an RGB color can
> still be supplied.
>
> -Terence Bandoian
>
>
> -
> 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: Transparent Splash Screen Background - Windows 10

[Jan Piotrowski]

It already is a tiny bit - but if you take care of that I will merge
it - nobody else seems to care either way (obviously), but I am
confident enough to merge this.

Thanks for your work!

-J

2018-01-19 8:43 GMT+01:00 Terence M. Bandoian :
> So should we go ahead and merge the PR before it becomes conflicted?
>
> -Terence
>
>
>
> On 1/11/2018 5:58 AM, Jan Piotrowski wrote:
>>
>> Sounds like a very useful change that will improve Cordova apps on
>> Windows.
>> +1
>>
>> 2018-01-11 11:56 GMT+01:00 Terence M. Bandoian :
>>>
>>> Julio suggested I bring this up for discussion so... related to:
>>>
>>>  CB-13641 - https://issues.apache.org/jira/browse/CB-13641
>>>  and https://github.com/apache/cordova-windows/pull/245
>>>
>>> I'd like to find out if there is any support for or objections to
>>> allowing
>>> transparent splash screen backgrounds on Windows.
>>>
>>> As you know, Cordova apps targeting Windows 10 execute on desktops and
>>> laptops in addition to tablets.  In that environment, some apps - the
>>> Settings app, for example - use the user-selected accent color for the
>>> splash background as well as the title bar background. Following that
>>> convention in some cases results in a more aesthetically pleasing startup
>>> than with a fixed color.  And, using 'transparent' as the splash
>>> background
>>> color value causes exactly that to take place.
>>>
>>> In the current splash screen implementation for Windows, both the title
>>> bar
>>> background and the window background are filled with the splash
>>> background
>>> color at startup.  Then, when the splash page is hidden, the title bar
>>> reverts to the user-selected accent color and the window to the app
>>> background which, depending on the colors in use, may not be a very
>>> appealing transition.
>>>
>>> In my case, I found using the accent color as the background much more
>>> satisfying which is why I went ahead and created the PR.  Other
>>> developers
>>> may find it useful as well.  And for those that don't, an RGB color can
>>> still be supplied.
>>>
>>> -Terence Bandoian
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

[DISCUSS] Cordova-Windows Release

[Jan Piotrowski]

Does anyone have any reason to delay a cordova-windows platform release?
Any outstanding patches to land?

If not, I will start the release soon.

J

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

Re: [DISCUSS] Cordova-Windows Release

[Jan Piotrowski]

Ok, so release is "in progress", meaning I fought/am fighting my way
through 
https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md

Now I encountered failing tests and the fact that CI was broken the
last few commits (tests were not run on AppVeyor). @alsorokin is
helping me dig through this, but it will probably take some time until
we are sure that we fixed everything and it is in a good state.

(Another thing that popped up is that CI didn't run the tests with
Visual Studio 2017, only 2015, but I committed a fix for that already)

Will update you when there is major progress.

Best,
Jan



2018-01-19 12:00 GMT+01:00 Jan Piotrowski :
> Does anyone have any reason to delay a cordova-windows platform release?
> Any outstanding patches to land?
>
> If not, I will start the release soon.
>
> J

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

Re: [DISCUSS] Cordova-Windows Release

[Jan Piotrowski]

Awesome.

I am working on it in #testing in Slack.

-J

2018-01-22 3:03 GMT+01:00 Jesse :
> I can help you thru this in a bit, give me a couple hours and I’ll jump in 
> there.
>
>> On Jan 21, 2018, at 11:00 AM, Jan Piotrowski  wrote:
>>
>> Ok, so release is "in progress", meaning I fought/am fighting my way
>> through 
>> https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md
>>
>> Now I encountered failing tests and the fact that CI was broken the
>> last few commits (tests were not run on AppVeyor). @alsorokin is
>> helping me dig through this, but it will probably take some time until
>> we are sure that we fixed everything and it is in a good state.
>>
>> (Another thing that popped up is that CI didn't run the tests with
>> Visual Studio 2017, only 2015, but I committed a fix for that already)
>>
>> Will update you when there is major progress.
>>
>> Best,
>> Jan
>>
>>
>>
>> 2018-01-19 12:00 GMT+01:00 Jan Piotrowski :
>>> Does anyone have any reason to delay a cordova-windows platform release?
>>> Any outstanding patches to land?
>>>
>>> If not, I will start the release soon.
>>>
>>> J
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Re: [DISCUSS] Cordova-Windows Release

[Jan Piotrowski]

Ok, found the culprit:

The default target version was changed from 8.1 to UAP/UWP, as VS-2017
doesn't include the tooling for the older ones any more.
This changes what files are created of course - but the tests are
checking for specific files right now.
What should we do about those tests?

Right now it is checking for a `.appxbundle` getting created, which is
not the case with UAP.
For UAP we also only get one app, not one build for Windows and one for Phone.

Is this ok in practical usage of cordova-windows?
Any feedback?

Current idea is to duplicate these tests and add a param to force 8.1
on one set of them, and modify the other set to look for the correct
files that _are_ there.

Best,
Jan


2018-01-22 11:33 GMT+01:00 Jan Piotrowski :
> Awesome.
>
> I am working on it in #testing in Slack.
>
> -J
>
> 2018-01-22 3:03 GMT+01:00 Jesse :
>> I can help you thru this in a bit, give me a couple hours and I’ll jump in 
>> there.
>>
>>> On Jan 21, 2018, at 11:00 AM, Jan Piotrowski  wrote:
>>>
>>> Ok, so release is "in progress", meaning I fought/am fighting my way
>>> through 
>>> https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md
>>>
>>> Now I encountered failing tests and the fact that CI was broken the
>>> last few commits (tests were not run on AppVeyor). @alsorokin is
>>> helping me dig through this, but it will probably take some time until
>>> we are sure that we fixed everything and it is in a good state.
>>>
>>> (Another thing that popped up is that CI didn't run the tests with
>>> Visual Studio 2017, only 2015, but I committed a fix for that already)
>>>
>>> Will update you when there is major progress.
>>>
>>> Best,
>>> Jan
>>>
>>>
>>>
>>> 2018-01-19 12:00 GMT+01:00 Jan Piotrowski :
>>>> Does anyone have any reason to delay a cordova-windows platform release?
>>>> Any outstanding patches to land?
>>>>
>>>> If not, I will start the release soon.
>>>>
>>>> J
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>

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

Re: [DISCUSS] Cordova-Windows Release

[Jan Piotrowski]

After further discussion with Jesse and @alsorokin I think this change
should be considered breaking and requires a 6.x release of
cordova-windows.

Release 5.1.0 is scrapped now, we are checking if it makes sense to
clean up "UWP vs. UAP" with this as well:
https://issues.apache.org/jira/projects/CB/issues/CB-13817

When this is done, I will start a 6.x release for cordova-windows.

Best,
Jan



2018-01-22 17:21 GMT+01:00 Jesse :
> We should be moving forward with uap only I think. Not even sure the store 
> will accept an 8.1 app any more.
> We should update the tests to match. imho
>
>> On Jan 22, 2018, at 8:08 AM, Jan Piotrowski  wrote:
>>
>> Ok, found the culprit:
>>
>> The default target version was changed from 8.1 to UAP/UWP, as VS-2017
>> doesn't include the tooling for the older ones any more.
>> This changes what files are created of course - but the tests are
>> checking for specific files right now.
>> What should we do about those tests?
>>
>> Right now it is checking for a `.appxbundle` getting created, which is
>> not the case with UAP.
>> For UAP we also only get one app, not one build for Windows and one for 
>> Phone.
>>
>> Is this ok in practical usage of cordova-windows?
>> Any feedback?
>>
>> Current idea is to duplicate these tests and add a param to force 8.1
>> on one set of them, and modify the other set to look for the correct
>> files that _are_ there.
>>
>> Best,
>> Jan
>>
>>
>> 2018-01-22 11:33 GMT+01:00 Jan Piotrowski :
>>> Awesome.
>>>
>>> I am working on it in #testing in Slack.
>>>
>>> -J
>>>
>>> 2018-01-22 3:03 GMT+01:00 Jesse :
>>>> I can help you thru this in a bit, give me a couple hours and I’ll jump in 
>>>> there.
>>>>
>>>>> On Jan 21, 2018, at 11:00 AM, Jan Piotrowski  wrote:
>>>>>
>>>>> Ok, so release is "in progress", meaning I fought/am fighting my way
>>>>> through 
>>>>> https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md
>>>>>
>>>>> Now I encountered failing tests and the fact that CI was broken the
>>>>> last few commits (tests were not run on AppVeyor). @alsorokin is
>>>>> helping me dig through this, but it will probably take some time until
>>>>> we are sure that we fixed everything and it is in a good state.
>>>>>
>>>>> (Another thing that popped up is that CI didn't run the tests with
>>>>> Visual Studio 2017, only 2015, but I committed a fix for that already)
>>>>>
>>>>> Will update you when there is major progress.
>>>>>
>>>>> Best,
>>>>> Jan
>>>>>
>>>>>
>>>>>
>>>>> 2018-01-19 12:00 GMT+01:00 Jan Piotrowski :
>>>>>> Does anyone have any reason to delay a cordova-windows platform release?
>>>>>> Any outstanding patches to land?
>>>>>>
>>>>>> If not, I will start the release soon.
>>>>>>
>>>>>> J
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>>>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>>>>
>>>>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

[DISCUSS] Cordova-Windows 6.0.0

[Jan Piotrowski]

Hello.

After we had to scrap release 5.1.0 because of an unexpected breaking
change (and broken CI and failing tests), I took the time to work a
bit on this and am now planning to go forward with a 6.0.0 release of
cordova-windows soonish.

Current status:

Must
- https://github.com/apache/cordova-windows/pull/246 (of
https://issues.apache.org/jira/browse/CB-13829) has to be reviewed and
merged
- https://issues.apache.org/jira/browse/CB-13834 has to be analyzed,
fixed, reviewed and merged

Maybe
- https://issues.apache.org/jira/browse/CB-13817 could implement "UWP"
everywhere we currently use "UAP" (which will be kept as an alias)
- https://github.com/apache/cordova-windows/pull/235 should be
reviewed and merged as it is a nice new feature for Windows

After
- Later https://github.com/apache/cordova-docs/pull/785 needs some
more work so docs at least partially match reality when 6.0.0 will be
released

Am I missing anything?

In the last release email Jesse suggested dropping 8.1 alltogether.
After spending some time with the code this would a) be super nice as
s much stuff could be deleted and removed but also b) pretty hard
as it is all connected and interwoven. Won't be quick to do.
More importantly I think we should use the release blog post to ask
cordova-windows users if 8.1 is still needed for them and how they are
using it in general so we get some input on how to proceed. (Some
feedback from Microsoft wouldn't be the worst idea either) If no one
uses it, we can do a clean 7.0.0 that removes it.

Best,
Jan

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

Re: [DISCUSS] Cordova-Windows 6.0.0

[Jan Piotrowski]

The failures in https://github.com/apache/cordova-windows/pull/235 are
unrelated to that PR. Those are caused by the "Musts": If
https://github.com/apache/cordova-windows/pull/246 gets merged this
will be down to one, and the last one is
https://issues.apache.org/jira/browse/CB-13834

-J

2018-01-26 1:12 GMT+01:00 Jesse :
> Yeah, I agree that dumping 8.1 completely would be a lot of work, let move
> forward without that part.
>
> I think I agree with all your assessments!
>
> For the maybes:
> I think CB-13817 <https://issues.apache.org/jira/browse/CB-13817> is less
> important, as it is something that even MS allows. They changed to call all
> UAP => UWP but they still have docs that say UAP.
> I would like to see https://github.com/apache/cordova-windows/pull/235 make
> it in, we'll need to look into the failures.
>
>
>
>
> @purplecabbage
> risingj.com
>
> On Thu, Jan 25, 2018 at 3:54 PM, Jan Piotrowski 
> wrote:
>
>> Hello.
>>
>> After we had to scrap release 5.1.0 because of an unexpected breaking
>> change (and broken CI and failing tests), I took the time to work a
>> bit on this and am now planning to go forward with a 6.0.0 release of
>> cordova-windows soonish.
>>
>> Current status:
>>
>> Must
>> - https://github.com/apache/cordova-windows/pull/246 (of
>> https://issues.apache.org/jira/browse/CB-13829) has to be reviewed and
>> merged
>> - https://issues.apache.org/jira/browse/CB-13834 has to be analyzed,
>> fixed, reviewed and merged
>>
>> Maybe
>> - https://issues.apache.org/jira/browse/CB-13817 could implement "UWP"
>> everywhere we currently use "UAP" (which will be kept as an alias)
>> - https://github.com/apache/cordova-windows/pull/235 should be
>> reviewed and merged as it is a nice new feature for Windows
>>
>> After
>> - Later https://github.com/apache/cordova-docs/pull/785 needs some
>> more work so docs at least partially match reality when 6.0.0 will be
>> released
>>
>> Am I missing anything?
>>
>> In the last release email Jesse suggested dropping 8.1 alltogether.
>> After spending some time with the code this would a) be super nice as
>> s much stuff could be deleted and removed but also b) pretty hard
>> as it is all connected and interwoven. Won't be quick to do.
>> More importantly I think we should use the release blog post to ask
>> cordova-windows users if 8.1 is still needed for them and how they are
>> using it in general so we get some input on how to proceed. (Some
>> feedback from Microsoft wouldn't be the worst idea either) If no one
>> uses it, we can do a clean 7.0.0 that removes it.
>>
>> Best,
>> Jan
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>

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

Re: [DISCUSS] Cordova-Windows 6.0.0

[Jan Piotrowski]

Ok, so #235 and #246 are merged into `master` and we are down to one
failing test case https://issues.apache.org/jira/browse/CB-13834

The test is failing with Visual Studio 2017 and I can't reproduce locally,
but it happens consistently on AppVeyor CI.
If anyone here has some time, it would be really helpful if you could check
out `master` and see if you can reproduce.

(Test runs of last commit to master can be seen here:
https://ci.appveyor.com/project/Humbedooh/cordova-windows/build/1.0.854)

Best,
Jan

2018-01-26 1:42 GMT+01:00 Jan Piotrowski :

> The failures in https://github.com/apache/cordova-windows/pull/235 are
> unrelated to that PR. Those are caused by the "Musts": If
> https://github.com/apache/cordova-windows/pull/246 gets merged this
> will be down to one, and the last one is
> https://issues.apache.org/jira/browse/CB-13834
>
> -J
>
> 2018-01-26 1:12 GMT+01:00 Jesse :
> > Yeah, I agree that dumping 8.1 completely would be a lot of work, let
> move
> > forward without that part.
> >
> > I think I agree with all your assessments!
> >
> > For the maybes:
> > I think CB-13817 <https://issues.apache.org/jira/browse/CB-13817> is
> less
> > important, as it is something that even MS allows. They changed to call
> all
> > UAP => UWP but they still have docs that say UAP.
> > I would like to see https://github.com/apache/cordova-windows/pull/235
> make
> > it in, we'll need to look into the failures.
> >
> >
> >
> >
> > @purplecabbage
> > risingj.com
> >
> > On Thu, Jan 25, 2018 at 3:54 PM, Jan Piotrowski 
> > wrote:
> >
> >> Hello.
> >>
> >> After we had to scrap release 5.1.0 because of an unexpected breaking
> >> change (and broken CI and failing tests), I took the time to work a
> >> bit on this and am now planning to go forward with a 6.0.0 release of
> >> cordova-windows soonish.
> >>
> >> Current status:
> >>
> >> Must
> >> - https://github.com/apache/cordova-windows/pull/246 (of
> >> https://issues.apache.org/jira/browse/CB-13829) has to be reviewed and
> >> merged
> >> - https://issues.apache.org/jira/browse/CB-13834 has to be analyzed,
> >> fixed, reviewed and merged
> >>
> >> Maybe
> >> - https://issues.apache.org/jira/browse/CB-13817 could implement "UWP"
> >> everywhere we currently use "UAP" (which will be kept as an alias)
> >> - https://github.com/apache/cordova-windows/pull/235 should be
> >> reviewed and merged as it is a nice new feature for Windows
> >>
> >> After
> >> - Later https://github.com/apache/cordova-docs/pull/785 needs some
> >> more work so docs at least partially match reality when 6.0.0 will be
> >> released
> >>
> >> Am I missing anything?
> >>
> >> In the last release email Jesse suggested dropping 8.1 alltogether.
> >> After spending some time with the code this would a) be super nice as
> >> s much stuff could be deleted and removed but also b) pretty hard
> >> as it is all connected and interwoven. Won't be quick to do.
> >> More importantly I think we should use the release blog post to ask
> >> cordova-windows users if 8.1 is still needed for them and how they are
> >> using it in general so we get some input on how to proceed. (Some
> >> feedback from Microsoft wouldn't be the worst idea either) If no one
> >> uses it, we can do a clean 7.0.0 that removes it.
> >>
> >> Best,
> >> Jan
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> >> For additional commands, e-mail: dev-h...@cordova.apache.org
> >>
> >>
>

Re: [DISCUSS] Mark cordova-windows 6.0.0-dev

[Jan Piotrowski]

Changing the version number is part of the release process:
https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md#prepare-release
We can discuss if this order makes sense, but that is the documented
process right now and should be followed.

@purplecabbage: PR https://github.com/apache/cordova-windows/pull/247 that
you mention Jesse is already part of master since 9 months ago:
https://github.com/apache/cordova-windows/commit/279816743f995510a1070a0bf77a3180f11e468a

Release 6.0.0 is discussed in a separate mailing list [DISCUSS] thread and
currently blocked by a broken test (see other thread for more information).

J

2018-02-08 8:27 GMT+01:00 Jesse :

> Hi Chris,
>
> Are you okay if we go ahead and pull in https://github.com/apache/
> cordova-windows/pull/247 rebase those changes into master also, and do a
> 6.0.0 release ( leaving windows 8.1 support in ) ?
>
>
>
>
> @purplecabbage
> risingj.com
>
> On Wed, Feb 7, 2018 at 7:18 PM, Chris Brody  wrote:
>
> > I meant something else. Change like the following commits:
> >
> >-
> >https://github.com/apache/cordova-windows/commit/
> > 34d1335187ac21f21061c638fd54364fa3afb422
> >-
> >https://github.com/apache/cordova-windows/commit/
> > ece4d0ffe16a0962c3c5d51c2289582f3d3238c9
> >
> > but change version / VERSION value to 6.0.0-dev.
> >
> > On Wed, Feb 7, 2018 at 10:10 PM, Shazron  wrote:
> >
> > > Do you mean a README update or something else?
> > >
> > > On Thu, Feb 8, 2018 at 10:59 AM, Chris Brody 
> > > wrote:
> > >
> > > > Hello team,
> > > >
> > > > I found out today that the cordova-windows master branch is now
> > targeting
> > > > 6.0.0 due to some breaking changes ref: http://markmail.org/
> > > > message/rzfa2zoydyjq6xso
> > > >
> > > > Can someone please mark this in the cordova-windows master branch?
> > > >
> > > > I think this could help avoid some possible forms of confusion moving
> > > > forward.
> > > >
> > > > Thanks and best regards,
> > > > Chris
> > > >
> > > > https://www.linkedin.com/in/chrisbrody/
> > > >
> > >
> >
>

Re: Fix crash on cordova-windows@5

[Jan Piotrowski]

I do not think this change necessitates a 5.0.1 or 5.1 release. Cutting
another release before 6.0.0 will just confuse people.
Just fork the repo and apply the change on your fork, then use that in your
app.

Although if anyone wants to run the release process, I of course won't stop
you. (But I will not but focus on 6.0.0).

J

2018-02-08 4:44 GMT+01:00 Chris Brody :

> Hello team,
>
> Windows 8.1 (8.1-win) build crashes in cordova-windows@5.0.0 (CB-12784 &
> CB-13175). It took multiple attempts to fix this on the cordova-windows
> master branch which I thought would be released 1-2 weeks ago for 5.1.0. I
> discovered today that the master branch is now for cordova-windows 6.0.0,
> blocked by a CI test failure. Very frustrating since I still support a
> special sqlite plugin version on Windows 8.1.
>
> I raised CB-13855 with a proposed fix for cordova-windows@5 in
> https://github.com/apache/cordova-windows/pull/247 (tested). As stated in
> PR #247 I did not do everything the usual way, purpose is to get this fixed
> ASAP.
>
> Please let me know if there is anything else you need me to do to get this
> fix into a new cordova-windows@5 release ASAP. It has been broken for way
> too long.
>
> Thanks and best regards,
> Chris
>
> https://www.linkedin.com/in/chrisbrody/
>

Re: Fix crash on cordova-windows@5

[Jan Piotrowski]

(5.x doesn't have the broken test because VS2017 wasn't a thing back then.
It's highly probably that if one would test 5.x with VS2017 it would also
be broken.)

(Broken test is https://issues.apache.org/jira/browse/CB-13834 if anyone
wants to help me debug/understand)

2018-02-08 13:05 GMT+01:00 Chris Brody :

> The 5.0.x branch does not have the failing test. This is why I proposed
> fixing the crash there.
>
> If 6.0.0 would be unblocked and released today then I would be happy.
>
> On Thu, Feb 8, 2018 at 6:57 AM, julio cesar sanchez <
> jcesarmob...@gmail.com>
> wrote:
>
> > The release of 6.0.0 is blocked because of a test, so a possible
> > 5.0.1/5.1.0 will probably be blocked for the same reason.
> >
> > If the 6.0.0 gets unblocked and can be released, is that good for you? or
> > you need the 5.0.1/5.1.0 for some reason?
> >
> > 2018-02-08 12:42 GMT+01:00 Chris Brody :
> >
> > > I was hoping to get this fixed for a customer. The last time I
> published
> > a
> > > change on my fork was was outdated pretty quickly. For now I will say
> > that
> > > they have to use cordova-android@4 for Windows 8.,1 until we get a new
> > > release with this crash resolved.
> > >
> > > Since #247 was already merged into 5.0.x I would be happiest to see it
> > > released. I do not see how this kind of a fix could confuse anyone. Or
> > am I
> > > missing something here?
> > >
> > > On Thu, Feb 8, 2018 at 6:03 AM, Jan Piotrowski 
> > > wrote:
> > >
> > > > I do not think this change necessitates a 5.0.1 or 5.1 release.
> Cutting
> > > > another release before 6.0.0 will just confuse people.
> > > > Just fork the repo and apply the change on your fork, then use that
> in
> > > your
> > > > app.
> > > >
> > > > Although if anyone wants to run the release process, I of course
> won't
> > > stop
> > > > you. (But I will not but focus on 6.0.0).
> > > >
> > > > J
> > > >
> > > > 2018-02-08 4:44 GMT+01:00 Chris Brody :
> > > >
> > > > > Hello team,
> > > > >
> > > > > Windows 8.1 (8.1-win) build crashes in cordova-windows@5.0.0
> > > (CB-12784 &
> > > > > CB-13175). It took multiple attempts to fix this on the
> > cordova-windows
> > > > > master branch which I thought would be released 1-2 weeks ago for
> > > 5.1.0.
> > > > I
> > > > > discovered today that the master branch is now for cordova-windows
> > > 6.0.0,
> > > > > blocked by a CI test failure. Very frustrating since I still
> support
> > a
> > > > > special sqlite plugin version on Windows 8.1.
> > > > >
> > > > > I raised CB-13855 with a proposed fix for cordova-windows@5 in
> > > > > https://github.com/apache/cordova-windows/pull/247 (tested). As
> > stated
> > > > in
> > > > > PR #247 I did not do everything the usual way, purpose is to get
> this
> > > > fixed
> > > > > ASAP.
> > > > >
> > > > > Please let me know if there is anything else you need me to do to
> get
> > > > this
> > > > > fix into a new cordova-windows@5 release ASAP. It has been broken
> > for
> > > > way
> > > > > too long.
> > > > >
> > > > > Thanks and best regards,
> > > > > Chris
> > > > >
> > > > > https://www.linkedin.com/in/chrisbrody/
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSS] Cordova-Windows 6.0.0

[Jan Piotrowski]

All that change existing functionality a user could depend on.

In this case:
https://issues.apache.org/jira/browse/CB-13237
Possibly also the ones disabling the tests (which happened before that one,
otherwise this would have been caught)

J

2018-02-08 17:06 GMT+01:00 Chris Brody :

> Can someone explain exactly which changes in the master branch should be
> considered "breaking"?
>

Re: [DISCUSS] Cordova-Windows 6.0.0

[Jan Piotrowski]

> I wonder if we should also consider CB-12499 to be breaking, considering
> that Default.rd.xml triggers the test failure on AppVeyor.

No. "Breaking" (in context of semver) refers to changing existing
functionality to not work any more or work differently.
CB-12499 just seems "broken" right now.

It introduces a new file and "link" to it in the Win10 project template:
https://github.com/apache/cordova-windows/pull/228/files And that file is
now causing issues with the test run with VS2017 on AppVeyor.

We now just have to get the test working and pass or revert that change for
now because we can't get it to work properly.
(In https://issues.apache.org/jira/browse/CB-13834 I mentioned the 2 people
involved in merging that functionality, maybe they can say more about it
over there).

> All tests are enabled now right?
> Or am I mistaken?

Yes.
No.

-J


2018-02-09 15:36 GMT+01:00 Chris Brody :

> I wonder if we should also consider CB-12499 to be breaking, considering
> that Default.rd.xml triggers the test failure on AppVeyor.
>
> All tests are enabled now right? Or am I mistaken?
>
> On Thu, Feb 8, 2018 at 12:49 PM, Jan Piotrowski 
> wrote:
>
> > All that change existing functionality a user could depend on.
> >
> > In this case:
> > https://issues.apache.org/jira/browse/CB-13237
> > Possibly also the ones disabling the tests (which happened before that
> one,
> > otherwise this would have been caught)
> >
> > J
> >
> > 2018-02-08 17:06 GMT+01:00 Chris Brody :
> >
> > > Can someone explain exactly which changes in the master branch should
> be
> > > considered "breaking"?
> > >
> >
>

Re: [DISCUSS] Cordova-Windows 6.0.0

[Jan Piotrowski]

Jesse, they do - but I am not sure why. Problem is I don't fully
understand what is going on there... which is why I am hesitant to
just ignore it.

> The tests pass on my machine if I would change  to
10.0.15063.0 (I don't have the old target platform SDK installed with VS
2017 and don't intend to add it there)

Chris, where and how exactly does one install the "target platform SDK"?
What happens if you do not change the `TargetPlatformVersion` manually
but have only that one installed?

> It is though the AppVeyor tests that Jan
already discovered some fixes that were needed for VS 2017, if I am not
mistaken. @Jan can you explain this further or am I mistaken somehow?

VS2017 did not exist at the time of the last release (or at least
nobody cared) so CI didn't use it to test. This should have been added
earlier, but I only added it 3 weeks ago with
https://github.com/apache/cordova-windows/commit/f5f4b21ad2c030ff61550bc947dca196c570f0ad
- which then showed this bug. (If any of the other failures that were
then fixes also were caused only by VS2017 I can not say
unfortunately)

J

2018-02-09 17:24 GMT+01:00 Chris Brody :
> P.S. I would not favor making a major version release before resolving the
> CI issue on AppVeyor somehow. It is though the AppVeyor tests that Jan
> already discovered some fixes that were needed for VS 2017, if I am not
> mistaken. @Jan can you explain this further or am I mistaken somehow?
>
> On Fri, Feb 9, 2018 at 11:17 AM, Chris Brody  wrote:
>
>> The tests pass on my machine if I would change  to
>> 10.0.15063.0 (I don't have the old target platform SDK installed with VS
>> 2017 and don't intend to add it there)
>>
>> On Fri, Feb 9, 2018 at 11:12 AM, Jesse  wrote:
>>
>>> Do the tests pass on your machines? If so, I think we should move forward
>>> with the 6.0.0 release, and write this off as a CI environment issue.
>>>
>>> On Feb 9, 2018, at 7:45 AM, Jan Piotrowski  wrote:
>>>
>>> >> I wonder if we should also consider CB-12499 to be breaking,
>>> considering
>>> >> that Default.rd.xml triggers the test failure on AppVeyor.
>>> >
>>> > No. "Breaking" (in context of semver) refers to changing existing
>>> > functionality to not work any more or work differently.
>>> > CB-12499 just seems "broken" right now.
>>> >
>>> > It introduces a new file and "link" to it in the Win10 project template:
>>> > https://github.com/apache/cordova-windows/pull/228/files And that file
>>> is
>>> > now causing issues with the test run with VS2017 on AppVeyor.
>>> >
>>> > We now just have to get the test working and pass or revert that change
>>> for
>>> > now because we can't get it to work properly.
>>> > (In https://issues.apache.org/jira/browse/CB-13834 I mentioned the 2
>>> people
>>> > involved in merging that functionality, maybe they can say more about it
>>> > over there).
>>> >
>>> >> All tests are enabled now right?
>>> >> Or am I mistaken?
>>> >
>>> > Yes.
>>> > No.
>>> >
>>> > -J
>>> >
>>> >
>>> > 2018-02-09 15:36 GMT+01:00 Chris Brody :
>>> >
>>> >> I wonder if we should also consider CB-12499 to be breaking,
>>> considering
>>> >> that Default.rd.xml triggers the test failure on AppVeyor.
>>> >>
>>> >> All tests are enabled now right? Or am I mistaken?
>>> >>
>>> >> On Thu, Feb 8, 2018 at 12:49 PM, Jan Piotrowski 
>>> >> wrote:
>>> >>
>>> >>> All that change existing functionality a user could depend on.
>>> >>>
>>> >>> In this case:
>>> >>> https://issues.apache.org/jira/browse/CB-13237
>>> >>> Possibly also the ones disabling the tests (which happened before that
>>> >> one,
>>> >>> otherwise this would have been caught)
>>> >>>
>>> >>> J
>>> >>>
>>> >>> 2018-02-08 17:06 GMT+01:00 Chris Brody :
>>> >>>
>>> >>>> Can someone explain exactly which changes in the master branch should
>>> >> be
>>> >>>> considered "breaking"?
>>> >>>>
>>> >>>
>>> >>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>>
>>>
>>

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

Re: [DISCUSS] Cordova-Windows 6.0.0

[Jan Piotrowski]

Ok, so this version can be compared to the iOS or Android API version?
Then it defintely makes sense to do some work to make this
configurable in a better way in the future.
Jesse, do you want to create the issue? You seem to have a specific
idea already.

To recap:
- We think the test failure is a problem only happening on AppVeyor
and should not affect actual users
- We are ok with starting a 6.0.0 release with the current `master`
state with this one failing test on AppVeyor
- We "pledge" to further look into it and release 6.0.1 or 6.1.0 if we
indeed find the solution

Agree?

If so, I will start the release process until Monday.

J

PS: I will contact AppVeyor to find out if they can maybe help -
blocked file, maybe because of some other running process?




2018-02-09 23:13 GMT+01:00 Jesse :
> There is a list of the timeline for all relevant versions here:
> https://docs.microsoft.com/en-us/windows/uwp/updates-and-versions/choose-a-uwp-version
>
> There are 2 important values at play:
> Target Version : this should probably be the most recent release we
> support, probably 16299
> Minimum Version : this should be as far back as we can go ...
> probably 10586
>
> Ultimately we will need to add a method to configure these values via
> config.xml preferences, but I don't think we should wait for that to happen.
>
> Changing these values on my windows machine meant all the tests passed, I
> had failing tests using master as-is.
>
> The failing test on appveyor is something different related to environment
> I believe.  Making these same changes that worked on my machine did not fix
> the fail on appveyor.
>
> I think we should go ahead with the 6.0.0 release, and plan to do a patch
> release in the near future when we work out the details of a configurable
> target/minimum version.
>
>
>
>
>
> @purplecabbage
> risingj.com
>
> On Fri, Feb 9, 2018 at 1:14 PM, Chris Brody  wrote:
>
>> On Feb 9, 2018 3:15 PM, "Jan Piotrowski"  wrote:
>>
>> Jesse, they do - but I am not sure why. Problem is I don't fully
>> understand what is going on there... which is why I am hesitant to
>> just ignore it.
>>
>>
>>
>> Makes sense to me
>>
>>
>> Chris, where and how exactly does one install the "target platform SDK"?
>>
>>
>>
>> Visual Studio 2017 comes with an installer program. It is possible to
>> install an older platform SDK version but I do not want to do this on my
>> PC.
>>
>>
>> What happens if you do not change the `TargetPlatformVersion` manually
>> but have only that one installed?
>>
>>
>>
>> I would get an error message that the needed platform SDK version does not
>> exist.
>>
>>
>> VS2017 did not exist at the time of the last release (or at least
>> nobody cared) so CI didn't use it to test.
>>
>>
>>
>> Makes sense
>>
>>
>> This should have been added
>> earlier, but I only added it 3 weeks ago with
>> https://github.com/apache/cordova-windows/commit/
>> f5f4b21ad2c030ff61550bc947dca196c570f0ad
>> - which then showed this bug.
>>
>>
>>
>> Good work on your part
>>
>>
>> (If any of the other failures that were
>> then fixes also were caused only by VS2017 I can not say
>> unfortunately)
>>
>>
>>
>> It would be nice to investigate and test this, if anyone has the time for
>> it.
>>

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

Re: [DISCUSS] Cordova-Windows 6.0.0

[Jan Piotrowski]

Well, during some more testing I noticed problems with `cordova requirements`:

> λ cordova requirements
> Requirements check results for windows:
> Windows OS: not installed
> Error: Cannot read property 'os' of undefined

The same is true for running `bin/check_reqs` directly which should do
the same/similar thing. After looking into that it seems like this way
to check the reqs is broken since a few years, so this is not a new
thing and won't hold up the release by itself, but I created two
issues about it: https://issues.apache.org/jira/browse/CB-13868
https://issues.apache.org/jira/browse/CB-13869

Back to `cordova requirements`: This also seems to be a follow up
problem of the change of the default platform from `8.1` to `UAP` - in
this case the script knows nothing about "UAP" but only "10.0".
Further I then noticed that different checks (VS2017 and MSBuild) are
missing version numbers here - so this currently can not work with
current tooling.
Issue for this is here: https://issues.apache.org/jira/browse/CB-13870

This will take some time :/

J

2018-02-11 2:03 GMT+01:00 Chris Brody :
> On Fri, Feb 9, 2018 at 8:01 PM, Terence M. Bandoian 
> wrote:
>
>> I'm not sure they're what you're looking for but there are three
>> version-related Windows preferences that seem to be supported in config.xml:
>>
>> 
>> > value="10.0.14393.0" />
>> > value="10.0.16299.125" />
>>
>> Does one or more of these resolve this?
>
>
> Does not seem to work for me
>
>
> On 2/9/2018 6:41 PM, Jesse wrote:
>>
>>> Created an issue for making this configurable. CB-13862
>>>
>>
> +1
>
> On Fri, Feb 9, 2018 at 4:23 PM, Jesse  wrote:
>>>
>>> All correct and I agree, except we do need to update TargetPlatformVersion
>>>> pr here: https://github.com/apache/cordova-windows/pull/250
>>>> Please test this pr on your windows machine and make sure you can create
>>>> and run a new cordova-windows project without having to modify the jsproj
>>>> file manually.
>>>>
>>>
> +1. As I said in cordova-windows PR#250 it works for me on Visual Studio
> 2015 and Visual Studio 2017. Ship it!
>
>
>
>> On Fri, Feb 9, 2018 at 3:37 PM, Jan Piotrowski 
>>>> wrote:
>>>>
>>>> To recap:
>>>>> - We think the test failure is a problem only happening on AppVeyor
>>>>> and should not affect actual users
>>>>> - We are ok with starting a 6.0.0 release with the current `master`
>>>>> state with this one failing test on AppVeyor
>>>>> - We "pledge" to further look into it and release 6.0.1 or 6.1.0 if we
>>>>> indeed find the solution
>>>>>
>>>>> Agree?
>>>>>
>>>>
> +1 agreed on my part
>
>
>> If so, I will start the release process until Monday.
>>>>>
>>>>
> +100
>
>
>> PS: I will contact AppVeyor to find out if they can maybe help -
>>>>> blocked file, maybe because of some other running process?
>>>>>
>>>>
> +1 thanks!

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

Re: [DISCUSS] Cordova-Windows 6.0.0

[Jan Piotrowski]

After some investigration I now understand the problem, see the update
on CB-13870. I consider this a blocking bug for a release of 6.0.0 as
`cordova requirements` functionality is broken with current tooling.

Let's see if we can fix this...

J

2018-02-12 13:42 GMT+01:00 Jan Piotrowski :
> Well, during some more testing I noticed problems with `cordova requirements`:
>
>> λ cordova requirements
>> Requirements check results for windows:
>> Windows OS: not installed
>> Error: Cannot read property 'os' of undefined
>
> The same is true for running `bin/check_reqs` directly which should do
> the same/similar thing. After looking into that it seems like this way
> to check the reqs is broken since a few years, so this is not a new
> thing and won't hold up the release by itself, but I created two
> issues about it: https://issues.apache.org/jira/browse/CB-13868
> https://issues.apache.org/jira/browse/CB-13869
>
> Back to `cordova requirements`: This also seems to be a follow up
> problem of the change of the default platform from `8.1` to `UAP` - in
> this case the script knows nothing about "UAP" but only "10.0".
> Further I then noticed that different checks (VS2017 and MSBuild) are
> missing version numbers here - so this currently can not work with
> current tooling.
> Issue for this is here: https://issues.apache.org/jira/browse/CB-13870
>
> This will take some time :/
>
> J
>
> 2018-02-11 2:03 GMT+01:00 Chris Brody :
>> On Fri, Feb 9, 2018 at 8:01 PM, Terence M. Bandoian 
>> wrote:
>>
>>> I'm not sure they're what you're looking for but there are three
>>> version-related Windows preferences that seem to be supported in config.xml:
>>>
>>> 
>>> >> value="10.0.14393.0" />
>>> >> value="10.0.16299.125" />
>>>
>>> Does one or more of these resolve this?
>>
>>
>> Does not seem to work for me
>>
>>
>> On 2/9/2018 6:41 PM, Jesse wrote:
>>>
>>>> Created an issue for making this configurable. CB-13862
>>>>
>>>
>> +1
>>
>> On Fri, Feb 9, 2018 at 4:23 PM, Jesse  wrote:
>>>>
>>>> All correct and I agree, except we do need to update TargetPlatformVersion
>>>>> pr here: https://github.com/apache/cordova-windows/pull/250
>>>>> Please test this pr on your windows machine and make sure you can create
>>>>> and run a new cordova-windows project without having to modify the jsproj
>>>>> file manually.
>>>>>
>>>>
>> +1. As I said in cordova-windows PR#250 it works for me on Visual Studio
>> 2015 and Visual Studio 2017. Ship it!
>>
>>
>>
>>> On Fri, Feb 9, 2018 at 3:37 PM, Jan Piotrowski 
>>>>> wrote:
>>>>>
>>>>> To recap:
>>>>>> - We think the test failure is a problem only happening on AppVeyor
>>>>>> and should not affect actual users
>>>>>> - We are ok with starting a 6.0.0 release with the current `master`
>>>>>> state with this one failing test on AppVeyor
>>>>>> - We "pledge" to further look into it and release 6.0.1 or 6.1.0 if we
>>>>>> indeed find the solution
>>>>>>
>>>>>> Agree?
>>>>>>
>>>>>
>> +1 agreed on my part
>>
>>
>>> If so, I will start the release process until Monday.
>>>>>>
>>>>>
>> +100
>>
>>
>>> PS: I will contact AppVeyor to find out if they can maybe help -
>>>>>> blocked file, maybe because of some other running process?
>>>>>>
>>>>>
>> +1 thanks!

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

Re: [DISCUSS] Cordova-Windows 6.0.0

[Jan Piotrowski]

Testing for CB-13870 showed that is is not only `cordova requirements`
that is broken with a new installation of VS2017, but the whole build
process is wonky:
https://issues.apache.org/jira/browse/CB-13872

There is a workaround setting an env var VSINSTALLDIR, but that is undocumented:
https://forum.ionicframework.com/t/building-windows-10-app/92416/9

Lucky for us MS seems to be aware of the problem, so this exists:
https://github.com/Microsoft/vswhere
`%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere" -all
-requires Microsoft.Component.MSBuild -property installationPath`
returns the correct path we want to look for the build tools, so we
can probably use that.
I will have to rewrite the MSBuildTools.js a bit, but that isn't the
worst idea anyway as it evolved over time and also has strange
duplication.

J

2018-02-12 14:52 GMT+01:00 Jan Piotrowski :
> After some investigration I now understand the problem, see the update
> on CB-13870. I consider this a blocking bug for a release of 6.0.0 as
> `cordova requirements` functionality is broken with current tooling.
>
> Let's see if we can fix this...
>
> J
>
> 2018-02-12 13:42 GMT+01:00 Jan Piotrowski :
>> Well, during some more testing I noticed problems with `cordova 
>> requirements`:
>>
>>> λ cordova requirements
>>> Requirements check results for windows:
>>> Windows OS: not installed
>>> Error: Cannot read property 'os' of undefined
>>
>> The same is true for running `bin/check_reqs` directly which should do
>> the same/similar thing. After looking into that it seems like this way
>> to check the reqs is broken since a few years, so this is not a new
>> thing and won't hold up the release by itself, but I created two
>> issues about it: https://issues.apache.org/jira/browse/CB-13868
>> https://issues.apache.org/jira/browse/CB-13869
>>
>> Back to `cordova requirements`: This also seems to be a follow up
>> problem of the change of the default platform from `8.1` to `UAP` - in
>> this case the script knows nothing about "UAP" but only "10.0".
>> Further I then noticed that different checks (VS2017 and MSBuild) are
>> missing version numbers here - so this currently can not work with
>> current tooling.
>> Issue for this is here: https://issues.apache.org/jira/browse/CB-13870
>>
>> This will take some time :/
>>
>> J
>>
>> 2018-02-11 2:03 GMT+01:00 Chris Brody :
>>> On Fri, Feb 9, 2018 at 8:01 PM, Terence M. Bandoian 
>>> wrote:
>>>
>>>> I'm not sure they're what you're looking for but there are three
>>>> version-related Windows preferences that seem to be supported in 
>>>> config.xml:
>>>>
>>>> 
>>>> >>> value="10.0.14393.0" />
>>>> >>> value="10.0.16299.125" />
>>>>
>>>> Does one or more of these resolve this?
>>>
>>>
>>> Does not seem to work for me
>>>
>>>
>>> On 2/9/2018 6:41 PM, Jesse wrote:
>>>>
>>>>> Created an issue for making this configurable. CB-13862
>>>>>
>>>>
>>> +1
>>>
>>> On Fri, Feb 9, 2018 at 4:23 PM, Jesse  wrote:
>>>>>
>>>>> All correct and I agree, except we do need to update TargetPlatformVersion
>>>>>> pr here: https://github.com/apache/cordova-windows/pull/250
>>>>>> Please test this pr on your windows machine and make sure you can create
>>>>>> and run a new cordova-windows project without having to modify the jsproj
>>>>>> file manually.
>>>>>>
>>>>>
>>> +1. As I said in cordova-windows PR#250 it works for me on Visual Studio
>>> 2015 and Visual Studio 2017. Ship it!
>>>
>>>
>>>
>>>> On Fri, Feb 9, 2018 at 3:37 PM, Jan Piotrowski 
>>>>>> wrote:
>>>>>>
>>>>>> To recap:
>>>>>>> - We think the test failure is a problem only happening on AppVeyor
>>>>>>> and should not affect actual users
>>>>>>> - We are ok with starting a 6.0.0 release with the current `master`
>>>>>>> state with this one failing test on AppVeyor
>>>>>>> - We "pledge" to further look into it and release 6.0.1 or 6.1.0 if we
>>>>>>> indeed find the solution
>>>>>>>
>>>>>>> Agree?
>>>>>>>
>>>>>>
>>> +1 agreed on my part
>>>
>>>
>>>> If so, I will start the release process until Monday.
>>>>>>>
>>>>>>
>>> +100
>>>
>>>
>>>> PS: I will contact AppVeyor to find out if they can maybe help -
>>>>>>> blocked file, maybe because of some other running process?
>>>>>>>
>>>>>>
>>> +1 thanks!

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

cordova-windows as first repo with activated GitHub issues?

[Jan Piotrowski]

Hi all!

As I am working towards a (bumpy...) 6.0.0 release of cordova-windows,
I also went through its JIRA issues again and resolved, closed or
moved some of them. I noticed that we are down to 1 page of ~50
issues: 
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CB%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20component%20%3D%20cordova-windows
Many of those are actually for plugins that have problems with the
Windows platform, only a hand full are actual current problems (and
most of those I hope to have resolved before the release).

Because of that I think `cordova-windows` would be an excellent
candidate to be the first Cordova repo in the apache org to activate
GitHub issues! No need to migrate anything and in the release blog
post for cordova-windows 6.0.0 we could already link to the GitHub
issues page for bug reports and feedback.

What do you think?
What has to happen to make this a reality?

Best,
Jan

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

Re: cordova-windows as first repo with activated GitHub issues?

[Jan Piotrowski]

Ok, thanks.
Then let's wait a bit to see if we get any -1 on this - then I will go
ahead and create the INFRA issue.

As this is our first repo I suggest we do _nothing_ in JIRA for now
but just point to the GitHub issues in the release blog post.
If everything goes well, we can decide how to handle issue migration
etc. for the other repos (and how to handle the remaining
cordova-windows issues [in this case manually closing them with a link
and note to refile if still relevant would be doable, but I guess not
for all other platforms and plugins]).

J

2018-02-13 16:52 GMT+01:00 Shazron :
> Just ask INFRA to enable GH issues on the repo, point them to the repo you
> want (in this case cordova-windows only), simple as that. As long as we
> have consensus of course, and I don't believe anyone will object.
>
> Issues on JIRA need to be either resolved, or migrated to GH (this will be
> some non-trivial work, which would need to be done anyway if we move other
> components to GH).
>
> A resolution could be closing the issue, and telling the issue reporter to
> file it on GH now if it is still relevant. But any new issues for the
> component should be closed, with the pointer to the new location.
>
>
> On Feb 13, 2018 at 11:43 PM, Chris Brody  wrote:
>
>
> +1 (+100) on my part
>
> @Shazron what should we expect INFRA to do to help us with this one?
>
> On Tue, Feb 13, 2018 at 10:29 AM, Shazron  wrote:
>
> +1.
> You need to file an issue with INFRA.
> https://issues.apache.org/jira/browse/INFRA
>
> On Tue, Feb 13, 2018 at 10:58 PM, Jan Piotrowski 
> wrote:
>
> Hi all!
>
> As I am working towards a (bumpy...) 6.0.0 release of cordova-windows,
> I also went through its JIRA issues again and resolved, closed or
> moved some of them. I noticed that we are down to 1 page of ~50
> issues: https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20CB%20AND%20status%20in%20(Open%2C%20%22In%20Progress%
> 22%2C%20Reopened)%20AND%20component%20%3D%20cordova-windows
> Many of those are actually for plugins that have problems with the
> Windows platform, only a hand full are actual current problems (and
> most of those I hope to have resolved before the release).
>
> Because of that I think `cordova-windows` would be an excellent
> candidate to be the first Cordova repo in the apache org to activate
> GitHub issues! No need to migrate anything and in the release blog
> post for cordova-windows 6.0.0 we could already link to the GitHub
> issues page for bug reports and feedback.
>
> What do you think?
> What has to happen to make this a reality?
>
> Best,
> Jan
>
> -
> 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-windows, AppVeyor: Enable Rolling builds, disable duplicate builds for PR/branches

[Jan Piotrowski]

Hi all.

Everybody who has worked on cordova-windows and AppVeyor knows that it
can take quite a long time until the builds actually start which is
caused by all the other Apache projects also using the same (free)
account, with only one build at a time.

But I noticed there are also some things we can do to create less builds:

AppVeyor has a configuration area like this:
https://issues.apache.org/jira/secure/attachment/12866418/screenshot-1.png

The first relevant option are "Rolling Builds":
https://www.appveyor.com/docs/build-configuration/#rolling-builds

> Whenever you do a new commit to the same branch OR pull request all current 
> queued/running builds for that branch or PR are cancelled and the new one is 
> queued. Other words, rolling builds make sure that only the most recent 
> commit is built.

I would say this is almost always what we actually want - just get the
last state of a branch/PR tested.

And the second thing is "Do not build feature branches with open Pull
Requests": https://github.com/appveyor/ci/issues/882

> when enabled check if there are any opened PRs for push branch and if there 
> any PRs build won't be started assuming there will be another build for PR(s).

1) has to be configured by INFRA, but 2) we can set ourselves in appveyor.yml.

Do you agree these both options should be enabled for cordova-windows?

Best,
Jan

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

Re: [DISCUSS] cordova-windows, AppVeyor: Enable Rolling builds, disable duplicate builds for PR/branches

[Jan Piotrowski]

Good point, thanks for the reminder.

Actually you can also create a `cordoa-windows` AppVeyor project for
apache/cordova-windows, not just for a fork (which I am currently not
using as I work in branches on the main repo directly). That way you
can just trigger builds for branches manually (via a manual call to
the REST API).

J

2018-02-13 23:03 GMT+01:00 Jesse :
> Just create your own appveyor account, and run it against your own fork for
> every commit.  I find it spins up WAY faster.
> https://ci.appveyor.com/project/purplecabbage/cordova-windows/history
>
> I also got rid of node versions matrix and decided to just test node v8 (
> for my own quick and dirty experiments )
>
>
> @purplecabbage
> risingj.com
>
> On Tue, Feb 13, 2018 at 1:36 PM, Jan Piotrowski 
> wrote:
>
>> Hi all.
>>
>> Everybody who has worked on cordova-windows and AppVeyor knows that it
>> can take quite a long time until the builds actually start which is
>> caused by all the other Apache projects also using the same (free)
>> account, with only one build at a time.
>>
>> But I noticed there are also some things we can do to create less builds:
>>
>> AppVeyor has a configuration area like this:
>> https://issues.apache.org/jira/secure/attachment/12866418/screenshot-1.png
>>
>> The first relevant option are "Rolling Builds":
>> https://www.appveyor.com/docs/build-configuration/#rolling-builds
>>
>> > Whenever you do a new commit to the same branch OR pull request all
>> current queued/running builds for that branch or PR are cancelled and the
>> new one is queued. Other words, rolling builds make sure that only the most
>> recent commit is built.
>>
>> I would say this is almost always what we actually want - just get the
>> last state of a branch/PR tested.
>>
>> And the second thing is "Do not build feature branches with open Pull
>> Requests": https://github.com/appveyor/ci/issues/882
>>
>> > when enabled check if there are any opened PRs for push branch and if
>> there any PRs build won't be started assuming there will be another build
>> for PR(s).
>>
>> 1) has to be configured by INFRA, but 2) we can set ourselves in
>> appveyor.yml.
>>
>> Do you agree these both options should be enabled for cordova-windows?
>>
>> Best,
>> Jan
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>

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

Re: [DISCUSS] Cordova-Windows 6.0.0

[Jan Piotrowski]

Another update:

- TargetPlatformVersion problem was solved by adding a `prepare` step
to the e2e tests
- `cordova requirements` is fixed for current setups
- VS2017 can not be used to build Win8.1 projects it seems (or did I
mess up?): https://issues.apache.org/jira/browse/CB-13874
- MSBuildTools selection is broken for current VS17 (15.5) and
different setups of it. Solution:
https://issues.apache.org/jira/browse/CB-13877 +
https://issues.apache.org/jira/browse/CB-13878
- That one specific test failure at AppVeyor is still being
investigated (no idea for now, maybe "just" an overlapping process
problem)

But progress is made.

J

2018-02-13 22:49 GMT+01:00 Terence M. Bandoian :
> There is also:
>
>
>
> It apparently has the same meaning as Windows.Universal-MinVersion but sets
> the value in the jsproj file vs the appxmanifest file.  Is there any reason
> a user would want different values in those two files?
>
> -Terence
>
>
>
> On 2/9/2018 7:01 PM, Terence M. Bandoian wrote:
>>
>> I'm not sure they're what you're looking for but there are three
>> version-related Windows preferences that seem to be supported in config.xml:
>>
>> 
>> > value="10.0.14393.0" />
>> > value="10.0.16299.125" />
>>
>> Does one or more of these resolve this?
>>
>> -Terence
>>
>>
>>
>> On 2/9/2018 6:41 PM, Jesse wrote:
>>>
>>> Created an issue for making this configurable. CB-13862
>>>
>>>
>>> @purplecabbage
>>> risingj.com
>>>
>>> On Fri, Feb 9, 2018 at 4:23 PM, Jesse  wrote:
>>>
>>>> All correct and I agree, except we do need to update
>>>> TargetPlatformVersion
>>>> pr here: https://github.com/apache/cordova-windows/pull/250
>>>> Please test this pr on your windows machine and make sure you can create
>>>> and run a new cordova-windows project without having to modify the
>>>> jsproj
>>>> file manually.
>>>>
>>>>
>>>> @purplecabbage
>>>> risingj.com
>>>>
>>>> On Fri, Feb 9, 2018 at 3:37 PM, Jan Piotrowski 
>>>> wrote:
>>>>
>>>>> Ok, so this version can be compared to the iOS or Android API version?
>>>>> Then it defintely makes sense to do some work to make this
>>>>> configurable in a better way in the future.
>>>>> Jesse, do you want to create the issue? You seem to have a specific
>>>>> idea already.
>>>>>
>>>>> To recap:
>>>>> - We think the test failure is a problem only happening on AppVeyor
>>>>> and should not affect actual users
>>>>> - We are ok with starting a 6.0.0 release with the current `master`
>>>>> state with this one failing test on AppVeyor
>>>>> - We "pledge" to further look into it and release 6.0.1 or 6.1.0 if we
>>>>> indeed find the solution
>>>>>
>>>>> Agree?
>>>>>
>>>>> If so, I will start the release process until Monday.
>>>>>
>>>>> J
>>>>>
>>>>> PS: I will contact AppVeyor to find out if they can maybe help -
>>>>> blocked file, maybe because of some other running process?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2018-02-09 23:13 GMT+01:00 Jesse :
>>>>>>
>>>>>> There is a list of the timeline for all relevant versions here:
>>>>>> https://docs.microsoft.com/en-us/windows/uwp/updates-and-ver
>>>>>
>>>>> sions/choose-a-uwp-version
>>>>>>
>>>>>> There are 2 important values at play:
>>>>>> Target Version : this should probably be the most recent release we
>>>>>> support, probably 16299
>>>>>> Minimum Version : this should be as far back as we can go ...
>>>>>> probably 10586
>>>>>>
>>>>>> Ultimately we will need to add a method to configure these values via
>>>>>> config.xml preferences, but I don't think we should wait for that to
>>>>>
>>>>> happen.
>>>>>>
>>>>>> Changing these values on my windows machine meant all the tests
>>>>>> passed,
>>>>>
>>>>> I
>>>>>>
>>>>>> had failing tests using master as-is.
>>>>>>
>&

Re: [DISCUSS] Cordova-Windows 6.0.0

[Jan Piotrowski]

Current state of master is pretty stable now. It would be really
helpful if you could help me test it.

Run these two commands in a project that is already using cordova-windows:

  cordova platform rm windows
  cordova platform add https://github.com/apache/cordova-windows

Use only the second line on existing projects without cordova-windows;
or if you want to test in a new project these:

  cordova create windowsMasterTest
  cordova platform add https://github.com/apache/cordova-windows

Then use `cordova build windows` to create a build or `cordova run
windows` to build, install and run it directly.

(As Windows10 is default in this version, add `-- --appx=8.1-win` or
`-- --appx=8.1-phone` to the command if you want to build for Windows
(Phone) 8.1)

Let me know of any unexpected errors or output you are getting. (If
something goes wrong, it would be helpful to include the output of
`cordova requirements windows` for environment information).
Also let me know if everything is fine of course - I actually prefer those ;)

Thank you!

Jan

2018-02-15 1:09 GMT+01:00 Jan Piotrowski :
> Another update:
>
> - TargetPlatformVersion problem was solved by adding a `prepare` step
> to the e2e tests
> - `cordova requirements` is fixed for current setups
> - VS2017 can not be used to build Win8.1 projects it seems (or did I
> mess up?): https://issues.apache.org/jira/browse/CB-13874
> - MSBuildTools selection is broken for current VS17 (15.5) and
> different setups of it. Solution:
> https://issues.apache.org/jira/browse/CB-13877 +
> https://issues.apache.org/jira/browse/CB-13878
> - That one specific test failure at AppVeyor is still being
> investigated (no idea for now, maybe "just" an overlapping process
> problem)
>
> But progress is made.
>
> J
>
> 2018-02-13 22:49 GMT+01:00 Terence M. Bandoian :
>> There is also:
>>
>>
>>
>> It apparently has the same meaning as Windows.Universal-MinVersion but sets
>> the value in the jsproj file vs the appxmanifest file.  Is there any reason
>> a user would want different values in those two files?
>>
>> -Terence
>>
>>
>>
>> On 2/9/2018 7:01 PM, Terence M. Bandoian wrote:
>>>
>>> I'm not sure they're what you're looking for but there are three
>>> version-related Windows preferences that seem to be supported in config.xml:
>>>
>>> 
>>> >> value="10.0.14393.0" />
>>> >> value="10.0.16299.125" />
>>>
>>> Does one or more of these resolve this?
>>>
>>> -Terence
>>>
>>>
>>>
>>> On 2/9/2018 6:41 PM, Jesse wrote:
>>>>
>>>> Created an issue for making this configurable. CB-13862
>>>>
>>>>
>>>> @purplecabbage
>>>> risingj.com
>>>>
>>>> On Fri, Feb 9, 2018 at 4:23 PM, Jesse  wrote:
>>>>
>>>>> All correct and I agree, except we do need to update
>>>>> TargetPlatformVersion
>>>>> pr here: https://github.com/apache/cordova-windows/pull/250
>>>>> Please test this pr on your windows machine and make sure you can create
>>>>> and run a new cordova-windows project without having to modify the
>>>>> jsproj
>>>>> file manually.
>>>>>
>>>>>
>>>>> @purplecabbage
>>>>> risingj.com
>>>>>
>>>>> On Fri, Feb 9, 2018 at 3:37 PM, Jan Piotrowski 
>>>>> wrote:
>>>>>
>>>>>> Ok, so this version can be compared to the iOS or Android API version?
>>>>>> Then it defintely makes sense to do some work to make this
>>>>>> configurable in a better way in the future.
>>>>>> Jesse, do you want to create the issue? You seem to have a specific
>>>>>> idea already.
>>>>>>
>>>>>> To recap:
>>>>>> - We think the test failure is a problem only happening on AppVeyor
>>>>>> and should not affect actual users
>>>>>> - We are ok with starting a 6.0.0 release with the current `master`
>>>>>> state with this one failing test on AppVeyor
>>>>>> - We "pledge" to further look into it and release 6.0.1 or 6.1.0 if we
>>>>>> indeed find the solution
>>>>>>
>>>>>> Agree?
>>>>>>
>>>>>> If so, I will start the release process until Monday.
>>>>>>
>>>>>> J
>>>>>>
>>>>>&g

[DISCUSS] Cordova-Android Release 6.0.0

[Jan Piotrowski]

Does anyone have any reason to delay a cordova-android platform release?
Any outstanding patches to land?

If not, I will start the release soon-ish.

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

Re: [DISCUSS] Cordova-Android Release 6.0.0

[Jan Piotrowski]

Meh, ignore please. I messed up the title :(

2018-02-19 16:57 GMT+01:00 Jan Piotrowski :
> Does anyone have any reason to delay a cordova-android platform release?
> Any outstanding patches to land?
>
> If not, I will start the release soon-ish.

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

[DISCUSS] Cordova-Windows Release 6.0.0

[Jan Piotrowski]

Does anyone have any reason to delay a cordova-windows platform release?
Any outstanding patches to land?

If not, I will start the release soon-ish.

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

Re: cordova-windows as first repo with activated GitHub issues?

[Jan Piotrowski]

Issue created: https://issues.apache.org/jira/browse/INFRA-16061

2018-02-13 17:01 GMT+01:00 Jan Piotrowski :
> Ok, thanks.
> Then let's wait a bit to see if we get any -1 on this - then I will go
> ahead and create the INFRA issue.
>
> As this is our first repo I suggest we do _nothing_ in JIRA for now
> but just point to the GitHub issues in the release blog post.
> If everything goes well, we can decide how to handle issue migration
> etc. for the other repos (and how to handle the remaining
> cordova-windows issues [in this case manually closing them with a link
> and note to refile if still relevant would be doable, but I guess not
> for all other platforms and plugins]).
>
> J
>
> 2018-02-13 16:52 GMT+01:00 Shazron :
>> Just ask INFRA to enable GH issues on the repo, point them to the repo you
>> want (in this case cordova-windows only), simple as that. As long as we
>> have consensus of course, and I don't believe anyone will object.
>>
>> Issues on JIRA need to be either resolved, or migrated to GH (this will be
>> some non-trivial work, which would need to be done anyway if we move other
>> components to GH).
>>
>> A resolution could be closing the issue, and telling the issue reporter to
>> file it on GH now if it is still relevant. But any new issues for the
>> component should be closed, with the pointer to the new location.
>>
>>
>> On Feb 13, 2018 at 11:43 PM, Chris Brody  wrote:
>>
>>
>> +1 (+100) on my part
>>
>> @Shazron what should we expect INFRA to do to help us with this one?
>>
>> On Tue, Feb 13, 2018 at 10:29 AM, Shazron  wrote:
>>
>> +1.
>> You need to file an issue with INFRA.
>> https://issues.apache.org/jira/browse/INFRA
>>
>> On Tue, Feb 13, 2018 at 10:58 PM, Jan Piotrowski 
>> wrote:
>>
>> Hi all!
>>
>> As I am working towards a (bumpy...) 6.0.0 release of cordova-windows,
>> I also went through its JIRA issues again and resolved, closed or
>> moved some of them. I noticed that we are down to 1 page of ~50
>> issues: https://issues.apache.org/jira/issues/?jql=project%20%
>> 3D%20CB%20AND%20status%20in%20(Open%2C%20%22In%20Progress%
>> 22%2C%20Reopened)%20AND%20component%20%3D%20cordova-windows
>> Many of those are actually for plugins that have problems with the
>> Windows platform, only a hand full are actual current problems (and
>> most of those I hope to have resolved before the release).
>>
>> Because of that I think `cordova-windows` would be an excellent
>> candidate to be the first Cordova repo in the apache org to activate
>> GitHub issues! No need to migrate anything and in the release blog
>> post for cordova-windows 6.0.0 we could already link to the GitHub
>> issues page for bug reports and feedback.
>>
>> What do you think?
>> What has to happen to make this a reality?
>>
>> Best,
>> Jan
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org

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

Re: [DISCUSS] Cordova-Windows Release 6.0.0

[Jan Piotrowski]

JIRA issue to follow the release: https://issues.apache.org/jira/browse/CB-13896

2018-02-19 16:58 GMT+01:00 Jan Piotrowski :
> Does anyone have any reason to delay a cordova-windows platform release?
> Any outstanding patches to land?
>
> If not, I will start the release soon-ish.

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

Re: cordova-windows as first repo with activated GitHub issues?

[Jan Piotrowski]

And already activated:
https://github.com/apache/cordova-windows/issues

2018-02-19 17:04 GMT+01:00 Jan Piotrowski :
> Issue created: https://issues.apache.org/jira/browse/INFRA-16061
>
> 2018-02-13 17:01 GMT+01:00 Jan Piotrowski :
>> Ok, thanks.
>> Then let's wait a bit to see if we get any -1 on this - then I will go
>> ahead and create the INFRA issue.
>>
>> As this is our first repo I suggest we do _nothing_ in JIRA for now
>> but just point to the GitHub issues in the release blog post.
>> If everything goes well, we can decide how to handle issue migration
>> etc. for the other repos (and how to handle the remaining
>> cordova-windows issues [in this case manually closing them with a link
>> and note to refile if still relevant would be doable, but I guess not
>> for all other platforms and plugins]).
>>
>> J
>>
>> 2018-02-13 16:52 GMT+01:00 Shazron :
>>> Just ask INFRA to enable GH issues on the repo, point them to the repo you
>>> want (in this case cordova-windows only), simple as that. As long as we
>>> have consensus of course, and I don't believe anyone will object.
>>>
>>> Issues on JIRA need to be either resolved, or migrated to GH (this will be
>>> some non-trivial work, which would need to be done anyway if we move other
>>> components to GH).
>>>
>>> A resolution could be closing the issue, and telling the issue reporter to
>>> file it on GH now if it is still relevant. But any new issues for the
>>> component should be closed, with the pointer to the new location.
>>>
>>>
>>> On Feb 13, 2018 at 11:43 PM, Chris Brody  wrote:
>>>
>>>
>>> +1 (+100) on my part
>>>
>>> @Shazron what should we expect INFRA to do to help us with this one?
>>>
>>> On Tue, Feb 13, 2018 at 10:29 AM, Shazron  wrote:
>>>
>>> +1.
>>> You need to file an issue with INFRA.
>>> https://issues.apache.org/jira/browse/INFRA
>>>
>>> On Tue, Feb 13, 2018 at 10:58 PM, Jan Piotrowski 
>>> wrote:
>>>
>>> Hi all!
>>>
>>> As I am working towards a (bumpy...) 6.0.0 release of cordova-windows,
>>> I also went through its JIRA issues again and resolved, closed or
>>> moved some of them. I noticed that we are down to 1 page of ~50
>>> issues: https://issues.apache.org/jira/issues/?jql=project%20%
>>> 3D%20CB%20AND%20status%20in%20(Open%2C%20%22In%20Progress%
>>> 22%2C%20Reopened)%20AND%20component%20%3D%20cordova-windows
>>> Many of those are actually for plugins that have problems with the
>>> Windows platform, only a hand full are actual current problems (and
>>> most of those I hope to have resolved before the release).
>>>
>>> Because of that I think `cordova-windows` would be an excellent
>>> candidate to be the first Cordova repo in the apache org to activate
>>> GitHub issues! No need to migrate anything and in the release blog
>>> post for cordova-windows 6.0.0 we could already link to the GitHub
>>> issues page for bug reports and feedback.
>>>
>>> What do you think?
>>> What has to happen to make this a reality?
>>>
>>> Best,
>>> Jan
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>> For additional commands, e-mail: dev-h...@cordova.apache.org

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

Re: [DISCUSS] cordova-android release

[Jan Piotrowski]

+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 
> 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

[VOTE] Cordova-Windows@6.0.0 Release

[Jan Piotrowski]

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

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

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

The package was published from its corresponding git tag:
cordova-windows: 6.0.0 (c40fedff1a)

Note that you can test it out via:

cordova platform add https://github.com/apache/cordova-windows#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
* Ran npm test in cordova-windows
* Ran mobile-spec tests and observed numerous (but expected) failures
* Created, built and ran a project with the /bin scripts
* Created, built and ran a project / hello world app using the CLI

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

Re: [VOTE] Cordova-Windows@6.0.0 Release

[Jan Piotrowski]

The vote has now closed. The results are:

Positive Binding Votes: 4

Jesse MacFadyen
Alexander Sorokin
Steven Gill
Jan Piotrowski

The vote has passed.

Thank you all.

2018-02-22 18:10 GMT+01:00 Jesse :
> I vote +1
>
> * Ran coho verify-archive
> * Ran coho audit-license-headers
> * Ran coho check-license
> * ran npm test
> * made sure blank app creates and builds
>
>
> @purplecabbage
> risingj.com
>
> On Thu, Feb 22, 2018 at 12:43 AM,  wrote:
>
>> I vote +1.
>>
>> * Verified archives via `coho verify-archive`
>> * Verified tag manually
>> * Verified that blank app creates correctly with platform
>> * Verified that blank app can be successfully built and ran
>> * Verified that platform can be updated from previous version
>> * Verified release notes
>> * Verified version
>> * Verified whitespace and Unicode compatibility
>> * Verified App Cert Kit compatibility
>>
>> -- Alexander Sorokin
>>
>> -Original Message-
>> From: Steven Gill 
>> Sent: Thursday, February 22, 2018 12:53 AM
>> To: dev@cordova.apache.org
>> Subject: Re: [VOTE] Cordova-Windows@6.0.0 Release
>>
>> I vote +1
>>
>> * Ran coho verify-archive
>> * Ran coho audit-license-headers
>> * Ran coho check-license
>> * ran npm test
>>
>> On Tue, Feb 20, 2018 at 2:51 PM, Jan Piotrowski 
>> wrote:
>>
>> > Please review and vote on this 6.0.0 Windows 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%2Fissue
>> > s.apache.org%2Fjira%2Fbrowse%2FCB-13896&data=04%7C01%7Cv-alsoro%40micr
>> > osoft.com%7Ccf68af32075a4250923508d5797582d1%7C72f988bf86f141af91ab2d7
>> > cd011db47%7C1%7C0%7C636548467964989739%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
>> > iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=yZE2V
>> > A%2FjZzXy1pr8kIFxk6BF8qt47L5bTKZwSKAn0bQ%3D&reserved=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-13896&data=04%7C01%7Cv-
>> > alsoro%40microsoft.com%7Ccf68af32075a4250923508d5797582d1%7C72f988bf86
>> > f141af91ab2d7cd011db47%7C1%7C0%7C636548467964989739%7CUnknown%7CTWFpbG
>> > Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-
>> > 1&sdata=P%2FvWPbAIsu98SS30Bh3GqhwYovVr9k9G4ZXtnaKBItY%3D&reserved=0
>> >
>> > The package was published from its corresponding git tag:
>> > cordova-windows: 6.0.0 (c40fedff1a)
>> >
>> > Note that you can test it out via:
>> >
>> > cordova platform add
>> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
>> > b.com%2Fapache%2Fcordova-windows%236.0.0&data=04%7C01%7Cv-alsoro%40mic
>> > rosoft.com%7Ccf68af32075a4250923508d5797582d1%7C72f988bf86f141af91ab2d
>> > 7cd011db47%7C1%7C0%7C636548467964989739%7CUnknown%7CTWFpbGZsb3d8eyJWIj
>> > oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=xcWS
>> > zNTvMxOKYgSK74VTAetloqSku7Fwx1gDrhAqA7I%3D&reserved=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%2Fgithu
>> > b.com%2Fapache%2Fcordova-coho%2Fblob%2Fmaster%2Fdocs%2Frelease-voting.
>> > md&data=04%7C01%7Cv-alsoro%40microsoft.com%7Ccf68af32075a4250923508d57
>> > 97582d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63654846796498973
>> > 9%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
>> > Ik1haWwifQ%3D%3D%7C-1&sdata=tOzos3t1Ys2s5CJvafWpXz7PQmLHhsg61qzFh7qNEM
>> > o%3D&reserved=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
>> > * Ran npm test in cordova-windows
>> > * Ran mobile-spec tests and observed numerous (but expected) failures
>> > * Created, built and ran a project with the /bin scripts
>> > * Created, built and ran a project / hello world app using the CLI
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> > For additional commands, e-mail: dev-h...@cordova.apache.org
>> >
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>

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

Translation Bankruptcy?

[Jan Piotrowski]

Hi all,

while doing some work on cordova-docs I also took a look at the
translations again.

Translations are (theoretically) done on Crowdin, synced from and to Github:
https://crowdin.com/project/cordova

Unfortunately this doesn't really seem to work:

1. There is no (working) documentation on how to import or export
files from or to Crowdin:
https://github.com/apache/cordova-docs/blob/master/doc/translate.md

2. There is no way to figure out the current state of the translations
vs. the actual documentation.
3. From looking at the languages I understand: Translations are _very_
outdated vs. the actual documentation.

4. There are translated files for files that do not exist in English any more:
https://issues.apache.org/jira/browse/CB-13161

5. There seem to be lots of auto translated bits in different
languages, also Source Code and other technical stuff was
(automatically) translated in several languages:
https://issues.apache.org/jira/browse/CB-11414

To summarize:
No translating is happening because of the above facts. The current
translations are out of date, unmaintained, contra productive or even
misleading.

My suggestion:
Let's just face it and declare translation bankruptcy.

We remove all translated content from the docs repo (latest + dev
version only) and redirect each link to the matching English version.

Agree?
Disagree?
Suggestions?

Best,
Jan

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

Re: Translation Bankruptcy?

[Jan Piotrowski]

Hi Andrey,

you are certainly not wrong. While cleaning up cordova-docs
documentation (about how to develop and build the documentation
website) I found many bits and pieces of processes that seem to have
worked one time, including many things about translations. I don't
know why or when this all got broken by what changes and what the plan
was back then.

So I just collected all that content at
https://github.com/apache/cordova-docs/blob/master/doc/translate.md

But as this unfortunately doesn't seem to have been used in the last
~2 years, the current state is - in my opinion - too broken to fix
(without major effort).

Best,
Jan

2018-02-27 19:18 GMT+01:00 Andrey Kurdumov :
> From my perspective, as a person who was trying to do translation of Russian 
> language alone, translation is already bankrupted after new docs website 
> design was implemented.
> The reason for my opinion was following
> - Documentation website was changed without thinking that keep translation 
> intact is difficult. As a result it was broken
> - People who change generation of website seriously think that machine 
> translated content is usable. I recommend them read in Chinese recent 
> articles in computational biology, or for example latest news about politics 
> each day and try to understand not ‘idea’ of what’s going on, but actually 
> understand details.
> - All tools which I create to support quick iteration of translations has to 
> be rewritten in the new implementation and now has to be re-implemented.
> - During migration all files was changed location and has to be revalidated 
> again for whole docs
>
> If documentation website would not be touched, and if any change in 
> implementation of docs website could be vetoed by people who do localization, 
> I don’t see point investing time in the localization to my native language 
> again. If I finish Russian , I could start translating to Ukrainian after 
> that, since this is language which I also know relatively good.
>
> Translation is time consuming, and if such efforts would be discarded just 
> for pure change of internal implementation, there no reason to even try.
>
> Sent from Mail for Windows 10
>
> From: Jan Piotrowski
> Sent: Tuesday, February 27, 2018 7:22 PM
> To: dev
> Subject: Translation Bankruptcy?
>
> Hi all,
>
> while doing some work on cordova-docs I also took a look at the
> translations again.
>
> Translations are (theoretically) done on Crowdin, synced from and to Github:
> https://crowdin.com/project/cordova
>
> Unfortunately this doesn't really seem to work:
>
> 1. There is no (working) documentation on how to import or export
> files from or to Crowdin:
> https://github.com/apache/cordova-docs/blob/master/doc/translate.md
>
> 2. There is no way to figure out the current state of the translations
> vs. the actual documentation.
> 3. From looking at the languages I understand: Translations are _very_
> outdated vs. the actual documentation.
>
> 4. There are translated files for files that do not exist in English any more:
> https://issues.apache.org/jira/browse/CB-13161
>
> 5. There seem to be lots of auto translated bits in different
> languages, also Source Code and other technical stuff was
> (automatically) translated in several languages:
> https://issues.apache.org/jira/browse/CB-11414
>
> To summarize:
> No translating is happening because of the above facts. The current
> translations are out of date, unmaintained, contra productive or even
> misleading.
>
> My suggestion:
> Let's just face it and declare translation bankruptcy.
>
> We remove all translated content from the docs repo (latest + dev
> version only) and redirect each link to the matching English version.
>
> Agree?
> Disagree?
> Suggestions?
>
> Best,
> Jan
>
> -
> 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: Stepping Back

[Jan Piotrowski]

That's a real shame, hope you landed in a interesting new area.
Thanks for your work over the years!

J

2018-06-20 20:22 GMT+02:00 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

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

Re: Cross-referencing GH issues?

[Jan Piotrowski]

Github issues have links, I would just include it in the description.
"Shorthand" for a link could also be `user/repo#123`.

-J

2018-07-17 19:49 GMT+02:00 Chris Brody :
> Suppose I would open a GH issue somewhere, then cross-reference it
> from a commit or a PR. But the original GH issue is in a different
> repository. Any idea how we can deal with this?
>
> -
> 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] [JIRA -> GitHub Issues] The way forward

[Jan Piotrowski]

While our repositories are already fully on GitHub [1], our issues
mainly still live in JIRA. We previously decided this should be
changed [2] so issues live with code.

We also did some first switches that were pretty successful:

https://github.com/apache/cordova-docs/issues
https://github.com/apache/cordova-windows/issues

So I suggest we move forward with the rest. Here is a list of stuff to do:


a) Enable GitHub issues on all repositories via INFRA ticket

b) Define and update Contributor documentation:
  * Contributor guidelines
- https://cordova.apache.org/contribute/contribute_guidelines.html
- https://cordova.apache.org/contribute/
- https://cordova.apache.org/contribute/issues.html
- https://github.com/apache/cordova-coho/search?l=Markdown&q=JIRA
=> https://github.com/apache/cordova-docs/issues/861
  * Issue template(s)
  * Pull Request template(s)
  * Github labels / issue triaging documentation
  * Usage of GitHub merge functionality
  * READMEs of all repositories
  * Prepare all these changes as PRs that can merged when a) is taken care of.

c) Define and document handling of security issues
=> https://github.com/apache/cordova-docs/issues/860

d) Define and execute issue migration from JIRA to GitHub
e) Define and execute "disabling" of JIRA (if applies)

Related:
- Check if ICLA documentation is correct and fix if necessary


Any input or objections?

I expect d) and e) to require some more discussion and planning, but
think it is ok to just leave this to be done later after everything
else was taken care of. Agree?

Did I miss any documents for b) that will have to be updated?


Best regards,
Jan


PS:

For future reference, the links I collected while researching the
previous work done and current state:

[1] Move repositories to Github / Gitbox for Apache Cordova:
https://lists.apache.org/thread.html/af0ec86818674bd1a8c4a9372685a9ae8e6200c478ad8e859606f3a3@%3Cdev.cordova.apache.org%3E
https://issues.apache.org/jira/browse/INFRA-14347
https://issues.apache.org/jira/browse/INFRA-14398
https://issues.apache.org/jira/browse/INFRA-14399
https://lists.apache.org/thread.html/23e927ad58441685a3fb3bbfe8e4d9f52369afa24e6e57f74b247d17@%3Cdev.cordova.apache.org%3E
https://issues.apache.org/jira/browse/INFRA-14994
https://issues.apache.org/jira/browse/INFRA-14815
https://lists.apache.org/thread.html/649d83cd05ae7029327cd4734ca42282426c5564b291257da1b8b75e@%3Cdev.cordova.apache.org%3E

[2] Migrate Jira issues over to Github:
https://issues.apache.org/jira/browse/CB-13157
https://github.com/audreyso/cordova-discuss/blob/6bece4125d389036461e25036e51e0fdfd712567/proposals/GithubMigration.md
https://github.com/apache/cordova-discuss/pull/75
https://lists.apache.org/thread.html/a992eaf62c8475a4576784ca3f9d8acc575220f0c53e6016bc4455e7@%3Cdev.cordova.apache.org%3E
https://issues.apache.org/jira/browse/INFRA-16503

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

Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward

[Jan Piotrowski]

The npm forum solves a very different problem for npm - they had too
much noise in Github issues because of the project's popularity. Too
much popularity is not one of Cordova's problems ;)

Many uses of cordova-discuss will be able to move to the individual
project repositories issues, maybe we can even think about getting rid
of it. Good thing to keep in mind after everything is migrated.
The mailing list can be used much more to just point people to a
specific issue (as I also did in my original mail here) where the
actual discussion will happen.

-J

2018-07-31 17:39 GMT+02:00 Chris Brody :
> +1 (+100) for migrating away from JIRA issues
>
> npm took a different approach that I am starting to really like: using
> npm.community (Discourse) with GitHub login for issues and discussions
>
> solves another major problem since I don't like mail list for
> discussing issues and cordova-discuss has proven to be such an
> unpopular repo
> On Tue, Jul 31, 2018 at 10:54 AM Jan Piotrowski  wrote:
>>
>> While our repositories are already fully on GitHub [1], our issues
>> mainly still live in JIRA. We previously decided this should be
>> changed [2] so issues live with code.
>>
>> We also did some first switches that were pretty successful:
>>
>> https://github.com/apache/cordova-docs/issues
>> https://github.com/apache/cordova-windows/issues
>>
>> So I suggest we move forward with the rest. Here is a list of stuff to do:
>>
>>
>> a) Enable GitHub issues on all repositories via INFRA ticket
>>
>> b) Define and update Contributor documentation:
>>   * Contributor guidelines
>> - https://cordova.apache.org/contribute/contribute_guidelines.html
>> - https://cordova.apache.org/contribute/
>> - https://cordova.apache.org/contribute/issues.html
>> - https://github.com/apache/cordova-coho/search?l=Markdown&q=JIRA
>> => https://github.com/apache/cordova-docs/issues/861
>>   * Issue template(s)
>>   * Pull Request template(s)
>>   * Github labels / issue triaging documentation
>>   * Usage of GitHub merge functionality
>>   * READMEs of all repositories
>>   * Prepare all these changes as PRs that can merged when a) is taken care 
>> of.
>>
>> c) Define and document handling of security issues
>> => https://github.com/apache/cordova-docs/issues/860
>>
>> d) Define and execute issue migration from JIRA to GitHub
>> e) Define and execute "disabling" of JIRA (if applies)
>>
>> Related:
>> - Check if ICLA documentation is correct and fix if necessary
>>
>>
>> Any input or objections?
>>
>> I expect d) and e) to require some more discussion and planning, but
>> think it is ok to just leave this to be done later after everything
>> else was taken care of. Agree?
>>
>> Did I miss any documents for b) that will have to be updated?
>>
>>
>> Best regards,
>> Jan
>>
>>
>> PS:
>>
>> For future reference, the links I collected while researching the
>> previous work done and current state:
>>
>> [1] Move repositories to Github / Gitbox for Apache Cordova:
>> https://lists.apache.org/thread.html/af0ec86818674bd1a8c4a9372685a9ae8e6200c478ad8e859606f3a3@%3Cdev.cordova.apache.org%3E
>> https://issues.apache.org/jira/browse/INFRA-14347
>> https://issues.apache.org/jira/browse/INFRA-14398
>> https://issues.apache.org/jira/browse/INFRA-14399
>> https://lists.apache.org/thread.html/23e927ad58441685a3fb3bbfe8e4d9f52369afa24e6e57f74b247d17@%3Cdev.cordova.apache.org%3E
>> https://issues.apache.org/jira/browse/INFRA-14994
>> https://issues.apache.org/jira/browse/INFRA-14815
>> https://lists.apache.org/thread.html/649d83cd05ae7029327cd4734ca42282426c5564b291257da1b8b75e@%3Cdev.cordova.apache.org%3E
>>
>> [2] Migrate Jira issues over to Github:
>> https://issues.apache.org/jira/browse/CB-13157
>> https://github.com/audreyso/cordova-discuss/blob/6bece4125d389036461e25036e51e0fdfd712567/proposals/GithubMigration.md
>> https://github.com/apache/cordova-discuss/pull/75
>> https://lists.apache.org/thread.html/a992eaf62c8475a4576784ca3f9d8acc575220f0c53e6016bc4455e7@%3Cdev.cordova.apache.org%3E
>> https://issues.apache.org/jira/browse/INFRA-16503
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Re: Better discussion forum?

[Jan Piotrowski]

It's an Apache thing:

>  Apache projects use mailing lists to coordinate development of the software 
> and administration of the organization. Mailing lists also serve as a primary 
> support channel where users can help each other learn to use the software.

https://apache.org/foundation/mailinglists.html


2018-07-31 19:10 GMT+02:00 Chris Brody :
> I would really love to see a better discussion forum for ideas. I
> think the mail list is not so handy for forums with cross-referencing
> and cordova-discuss proved to be a failure. npm.community seems to
> have nailed it, though it may have been meant to solve another
> problem. Any comments?
>
> -
> 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: Time to mark major Cordova release & remove committed node_modules?

[Jan Piotrowski]

So this would e.g. bump cordova-windows master from 6.1.0-dev to
7.0.0-dev, so it would be clear that the next release would most
probably be a major one, correct?

Actual release of that version would only happen if there are enough
"real" changes that justify a major release anyway, right?

-J

2018-07-31 22:37 GMT+02:00  :
> +1
>
> Chris Brody  schrieb am Di., 31. Juli 2018, 21:23:
>
>> Exactly, thanks for the clarification.
>> On Tue, Jul 31, 2018 at 3:19 PM Darryl Pogue  wrote:
>> >
>> > +1
>> >
>> > Just to be clear, we're proposing to bump to the next major -dev
>> > version, not actually making any major version releases yet, correct?
>> > i.e., cordova-ios 4.6.0-dev -> cordova-ios 5.0.0-dev
>> >
>> > On Tue, Jul 31, 2018 at 12:14 PM Chris Brody 
>> wrote:
>> > >
>> > > Now that we have dropped support for deprecated Node.js 4 in master
>> > > branch of most repos, I think it is high time to do the following:
>> > > * mark next major release version in the affected repos
>> > > * remove committed node_modules from the affected platform repos
>> > >
>> > > I would like to request feedback within the next 1-2 days in case of
>> > > any objections. I would like to proceed with these items within the
>> > > next week in case there are no major objections.
>> > >
>> > > -
>> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> > > For additional commands, e-mail: dev-h...@cordova.apache.org
>> > >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> > For additional commands, e-mail: dev-h...@cordova.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>

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

Re: Activate issues on all active Cordova repos?

[Jan Piotrowski]

See this [DISCUSS] thread from yesterday:
https://lists.apache.org/thread.html/b08341c97a0b9de8207681d601773fc3e697734889284d806d44270f@%3Cdev.cordova.apache.org%3E

Please keep discussion on that topic there.

-J

2018-08-01 9:07 GMT+02:00 Chris Brody :
> I think this is needed pretty badly. I think JIRA is not so convenient
> for lower-level task management (i.e. developer todo-lists,
> discussions, etc.). Examples of discussions in PRs that should have
> been in issues (not yet available on cordova-ios):
> * https://github.com/apache/cordova-ios/pull/377
> * https://github.com/apache/cordova-ios/pull/382
> * https://github.com/apache/cordova-ios/pull/386
>
> Any idea what it would take to make this happen and how long we will
> have to wait?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward

[Jan Piotrowski]

Another one:

f) Find and activate way for Github issue (and PR) updates to be
posted so Slack #issues

2018-07-31 18:14 GMT+02:00 Jan Piotrowski :
> The npm forum solves a very different problem for npm - they had too
> much noise in Github issues because of the project's popularity. Too
> much popularity is not one of Cordova's problems ;)
>
> Many uses of cordova-discuss will be able to move to the individual
> project repositories issues, maybe we can even think about getting rid
> of it. Good thing to keep in mind after everything is migrated.
> The mailing list can be used much more to just point people to a
> specific issue (as I also did in my original mail here) where the
> actual discussion will happen.
>
> -J
>
> 2018-07-31 17:39 GMT+02:00 Chris Brody :
>> +1 (+100) for migrating away from JIRA issues
>>
>> npm took a different approach that I am starting to really like: using
>> npm.community (Discourse) with GitHub login for issues and discussions
>>
>> solves another major problem since I don't like mail list for
>> discussing issues and cordova-discuss has proven to be such an
>> unpopular repo
>> On Tue, Jul 31, 2018 at 10:54 AM Jan Piotrowski  wrote:
>>>
>>> While our repositories are already fully on GitHub [1], our issues
>>> mainly still live in JIRA. We previously decided this should be
>>> changed [2] so issues live with code.
>>>
>>> We also did some first switches that were pretty successful:
>>>
>>> https://github.com/apache/cordova-docs/issues
>>> https://github.com/apache/cordova-windows/issues
>>>
>>> So I suggest we move forward with the rest. Here is a list of stuff to do:
>>>
>>>
>>> a) Enable GitHub issues on all repositories via INFRA ticket
>>>
>>> b) Define and update Contributor documentation:
>>>   * Contributor guidelines
>>> - https://cordova.apache.org/contribute/contribute_guidelines.html
>>> - https://cordova.apache.org/contribute/
>>> - https://cordova.apache.org/contribute/issues.html
>>> - https://github.com/apache/cordova-coho/search?l=Markdown&q=JIRA
>>> => https://github.com/apache/cordova-docs/issues/861
>>>   * Issue template(s)
>>>   * Pull Request template(s)
>>>   * Github labels / issue triaging documentation
>>>   * Usage of GitHub merge functionality
>>>   * READMEs of all repositories
>>>   * Prepare all these changes as PRs that can merged when a) is taken care 
>>> of.
>>>
>>> c) Define and document handling of security issues
>>> => https://github.com/apache/cordova-docs/issues/860
>>>
>>> d) Define and execute issue migration from JIRA to GitHub
>>> e) Define and execute "disabling" of JIRA (if applies)
>>>
>>> Related:
>>> - Check if ICLA documentation is correct and fix if necessary
>>>
>>>
>>> Any input or objections?
>>>
>>> I expect d) and e) to require some more discussion and planning, but
>>> think it is ok to just leave this to be done later after everything
>>> else was taken care of. Agree?
>>>
>>> Did I miss any documents for b) that will have to be updated?
>>>
>>>
>>> Best regards,
>>> Jan
>>>
>>>
>>> PS:
>>>
>>> For future reference, the links I collected while researching the
>>> previous work done and current state:
>>>
>>> [1] Move repositories to Github / Gitbox for Apache Cordova:
>>> https://lists.apache.org/thread.html/af0ec86818674bd1a8c4a9372685a9ae8e6200c478ad8e859606f3a3@%3Cdev.cordova.apache.org%3E
>>> https://issues.apache.org/jira/browse/INFRA-14347
>>> https://issues.apache.org/jira/browse/INFRA-14398
>>> https://issues.apache.org/jira/browse/INFRA-14399
>>> https://lists.apache.org/thread.html/23e927ad58441685a3fb3bbfe8e4d9f52369afa24e6e57f74b247d17@%3Cdev.cordova.apache.org%3E
>>> https://issues.apache.org/jira/browse/INFRA-14994
>>> https://issues.apache.org/jira/browse/INFRA-14815
>>> https://lists.apache.org/thread.html/649d83cd05ae7029327cd4734ca42282426c5564b291257da1b8b75e@%3Cdev.cordova.apache.org%3E
>>>
>>> [2] Migrate Jira issues over to Github:
>>> https://issues.apache.org/jira/browse/CB-13157
>>> https://github.com/audreyso/cordova-discuss/blob/6bece4125d389036461e25036e51e0fdfd712567/proposals/GithubMigration.md
>>> https://github.com/apache/cordova-discuss/pull/75
>>> https://lists.apache.org/thread.html/a992eaf62c8475a4576784ca3f9d8acc575220f0c53e6016bc4455e7@%3Cdev.cordova.apache.org%3E
>>> https://issues.apache.org/jira/browse/INFRA-16503
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>

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

Re: Commit package-lock.json in next major Cordova release or not?

[Jan Piotrowski]

+1 - everything that modernizes the tooling that can be used and
actually uses its added functionality is a win.

2018-08-02 7:43 GMT+02:00 Chris Brody :
> Just raised https://issues.apache.org/jira/browse/CB-14248
>
> Thanks for the helpful responses
> On Thu, Aug 2, 2018 at 12:12 AM Shazron  wrote:
>>
>> yes +1
>> On Thu, Aug 2, 2018 at 4:28 AM Chris Brody  wrote:
>> >
>> > I think we should start to commit package-lock.json in the next major
>> > release but am not 100% sure. My understanding is that
>> > package-lock.json mostly serves a couple major purposes:
>> > * preserve the structure of node_modules cross-platform
>> > * use SHA numbers to verify correct packages
>> >
>> > There seem to have been changes between npm@4 (??), npm@5, and npm@6,
>> > as described in the following:
>> > * https://github.com/npm/npm/issues/20434 (npm@5 vs npm@6)
>> > * https://jpospisil.com/2017/06/02/understanding-lock-files-in-npm-5.html
>> >
>> > From what I read I think npm@5 & npm@6 would continue to follow the
>> > semver rules for packages specified in package.json.
>> >
>> > Major advantages I can think of:
>> > * better consistency for cross-platform development
>> > * no need to regenerate package-lock.json for npm audit check
>> >
>> > But I can think of the following possible disadvantages to consider:
>> > * not as easy to update dependencies, probably not possible to just
>> > update dependencies by hand
>> > * some additional "noise" in the git history, shouldn't be too bad though
>> > * possibly major: in case people work on different dependency changes
>> > in parallel and want to merge by git merge, rebase, or cherry-pick
>> > dealing with the package-lock.json changes may not be so clean
>> >
>> > and a counter-point:
>> > * 
>> > https://www.codementor.io/johnkennedy/get-rid-of-that-npm-package-lock-json-e0bj7ai42
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> > For additional commands, e-mail: dev-h...@cordova.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

[cordova-android] Fwd: Important reminder about Android targetSdkVersion requirement

[Jan Piotrowski]

Anything we should do about that for Cordova Android or the default Cordova
project?
What should other projects using Cordova Android do? (e.g. Ionic)

-J


-- Forwarded message --
From: Google Play 
Date: 2018-08-02 4:51 GMT+02:00
Subject: Important reminder about Android targetSdkVersion requirement
To: piotrow...@gmail.com


View as webpage  »

[image: Google Play] <#m_-8941348242845729157_> Developer update

Hello Google Play Developer,

This is a reminder

that starting *November 1, 2018*, updates to apps and games on Google Play
will be required to target Android Oreo (API level 26) or higher. After
this date, the Play Console will prevent you from submitting new APKs with
a targetSdkVersion less than 26.

Configuring your app to target a recent API level ensures that users
benefit from significant security and performance improvements, while still
allowing your app to run on older Android versions (down to the
minSdkVersion).

*Action required*

Please ensure that your apps are configured to target at least Android 8.0
(API level 26) by *November 1, 2018*. For technical advice on how to change
your app's target API level to meet these requirements, refer to the migration
guide
.


*Affected apps*

The apps included below have one or more APKs—in production or testing
tracks—that aren't currently targeting API level 26 or higher. Apps are
listed with the maximum version code and corresponding targetSdkVersion. If
you have more than 20 apps that could be affected in your account, please
check the Play Console

for a full list.
de.janpiotrowski.zaehlerstand   3   25
The Google Play Team [image: Conversation]

[image:
Globe]

© 2018 Google LLC 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA.
<#m_-8941348242845729157_>
Email preferences: You have received this mandatory email service
announcement to update you about important changes to your Google Play
Developer account.

Re: Do another cordova-android patch release?

[Jan Piotrowski]

> Also considered adding this one about Android Studio compatibility, but was
> not sure if the change might be considered breaking or at least minor, so
> didn't do it.

What would be an argument for this to be considered breaking?

2018-08-02 13:26 GMT+02:00 julio cesar sanchez :
> I've sent the PR with the cherry pick
>
> https://github.com/apache/cordova-android/pull/469
>
> It include 4 commits, 3 related to the plugins and another one about
> simulator failing to launch.
>
> Also considered adding this one about Android Studio compatibility, but was
> not sure if the change might be considered breaking or at least minor, so
> didn't do it.
>
> https://github.com/apache/cordova-android/commit/
> 5c4f8ca24629486847d363921d1aaa0a69f5
>
>
>
> 2018-07-31 0:47 GMT+02:00 Chris Brody :
>
>> I would favor raising a JIRA issue to port those changes and port by
>> cherry-pick. I would also favor not including any non-essential
>> changes in such a patch release.
>> On Mon, Jul 30, 2018 at 6:39 PM julio cesar sanchez
>>  wrote:
>> >
>> > So starting in August, using at least SDK 26 as target will be mandatory
>> > for submitting to google play.
>> > The first cordova-android that targeted SDK 26 was 7.0.0, but a lot of
>> > people is not updating because of breaking changes and plugins failing to
>> > install because of them.
>> > We have fixed the plugin compatibility in master, so I think it would be
>> > good to do a new patch release with those fixes included.
>> >
>> > So, what should we do to add those fixes to a new release? just
>> cherry-pick
>> > the commits to the 7.1.x branch? With a PR or we have to use some tool
>> > (like coho)?
>> >
>> > Those are the two PRs I'm talking about
>> >
>> > https://github.com/apache/cordova-android/pull/449
>> > https://github.com/apache/cordova-android/pull/437
>> >
>> > Any other PR/commit that could be included if it's not breaking?
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>

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

Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward

[Jan Piotrowski]

Decision making for Apache projects is described here:
https://community.apache.org/committers/decisionMaking.html

So to make it official:
I hereby declare that I will start implementing the stuff from my
initial email if nobody objects in the next 72 hours (meaning: before
next Monday). After that I will create the INFRA issue.

The other, preliminary taks can already be started - I did by creating
2 cordova-docs issues that I already linked. For the rest of b) I will
probably start another mailing list thread.

2018-08-02 15:35 GMT+02:00 Chris Brody :
> What will it take to take care of a) Enable GitHub issues on all
> repositories via INFRA ticket?
>
> I think this is needed really badly. There are way too many cases of
> questions and issues being raised in the wrong place, lost in diverse
> discussion forums, or not even asked at all.
> On Wed, Aug 1, 2018 at 9:59 AM Bryan Ellis  wrote:
>>
>> +1
>>
>> Not sure if (f) was a task, as in to find a way to integrate GH and Slack, 
>> but it does exist.
>>
>> https://slack.github.com/ <https://slack.github.com/>
>>
>> It covers a lot including new commits, pr, new issues, code reviews, and 
>> more.
>>
>>
>> > On Aug 1, 2018, at 22:22, Jan Piotrowski  wrote:
>> >
>> > Another one:
>> >
>> > f) Find and activate way for Github issue (and PR) updates to be
>> > posted so Slack #issues
>> >
>> > 2018-07-31 18:14 GMT+02:00 Jan Piotrowski :
>> >> The npm forum solves a very different problem for npm - they had too
>> >> much noise in Github issues because of the project's popularity. Too
>> >> much popularity is not one of Cordova's problems ;)
>> >>
>> >> Many uses of cordova-discuss will be able to move to the individual
>> >> project repositories issues, maybe we can even think about getting rid
>> >> of it. Good thing to keep in mind after everything is migrated.
>> >> The mailing list can be used much more to just point people to a
>> >> specific issue (as I also did in my original mail here) where the
>> >> actual discussion will happen.
>> >>
>> >> -J
>> >>
>> >> 2018-07-31 17:39 GMT+02:00 Chris Brody :
>> >>> +1 (+100) for migrating away from JIRA issues
>> >>>
>> >>> npm took a different approach that I am starting to really like: using
>> >>> npm.community (Discourse) with GitHub login for issues and discussions
>> >>>
>> >>> solves another major problem since I don't like mail list for
>> >>> discussing issues and cordova-discuss has proven to be such an
>> >>> unpopular repo
>> >>> On Tue, Jul 31, 2018 at 10:54 AM Jan Piotrowski  
>> >>> wrote:
>> >>>>
>> >>>> While our repositories are already fully on GitHub [1], our issues
>> >>>> mainly still live in JIRA. We previously decided this should be
>> >>>> changed [2] so issues live with code.
>> >>>>
>> >>>> We also did some first switches that were pretty successful:
>> >>>>
>> >>>> https://github.com/apache/cordova-docs/issues
>> >>>> https://github.com/apache/cordova-windows/issues
>> >>>>
>> >>>> So I suggest we move forward with the rest. Here is a list of stuff to 
>> >>>> do:
>> >>>>
>> >>>>
>> >>>> a) Enable GitHub issues on all repositories via INFRA ticket
>> >>>>
>> >>>> b) Define and update Contributor documentation:
>> >>>>  * Contributor guidelines
>> >>>>- https://cordova.apache.org/contribute/contribute_guidelines.html
>> >>>>- https://cordova.apache.org/contribute/
>> >>>>- https://cordova.apache.org/contribute/issues.html
>> >>>>- https://github.com/apache/cordova-coho/search?l=Markdown&q=JIRA
>> >>>>=> https://github.com/apache/cordova-docs/issues/861
>> >>>>  * Issue template(s)
>> >>>>  * Pull Request template(s)
>> >>>>  * Github labels / issue triaging documentation
>> >>>>  * Usage of GitHub merge functionality
>> >>>>  * READMEs of all repositories
>> >>>>  * Prepare all these changes as PRs that can merged when a) is taken 
>> >>>> care of.
>> >>>>
>> >>>> c) Define and 

Re: ios-deploy questions

[Jan Piotrowski]

> 1. Why not make ios-deploy a dependency of cordova-ios that would then
> be automatically installed?

Historically, I think, commands that should be able to be called via
the command line had to be installed globally with npm to work. Is
this not the case any more?

2018-08-02 15:26 GMT+02:00 Chris Brody :
> A couple things that I think are not clear for
> :
>
> 1. Why not make ios-deploy a dependency of cordova-ios that would then
> be automatically installed?
>
> 2. Is there a risk of mismatch between a users installed ios-deploy
> version and a users Cordova version? Should this be documented, if so?
>
> I think the answer to 1 is that ios-deploy sometimes needs to be
> installed with more system privs. I am not 100% sure of this, would
> love some confirmation from an expert. And I think this is not really
> a problem most of the time.
>
> I think the answer to 2 is "not yet".
>
> Confirmation would be really helpful.
>
> -
> 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: WKWebView plugin - issues before baking it in to cordova-ios

[Jan Piotrowski]

Many Cordova users out there are probably using
https://github.com/ionic-team/cordova-plugin-ionic-webview. Does this
play any role in regards to the blog post? Should this maybe be
mentioned as an anticipated question?

2018-08-02 16:31 GMT+02:00 Shazron :
> Please review the draft of the blog post about this:
> "The Future of the iOS WebView in Apache Cordova"
> https://github.com/apache/cordova-docs/pull/867
> On Mon, Jul 16, 2018 at 2:38 PM Shazron  wrote:
>>
>> I've done with my review with all the issues that need to resolved
>> with the plugin before it can be baked in to the platform for a major
>> version release. I'm going to discuss issues with respect to migration
>> of developers from UIWebView (features that will be lost or are
>> different)
>>
>> 1. Cookies don't persist. This is a WebKit bug, but someone has
>> created a plugin for a workaround. See
>> https://issues.apache.org/jira/browse/CB-12074
>> 2. Can't delete cookies. This is/was a WebKit bug (2015), need to test
>> for the iOS 11/12. See https://issues.apache.org/jira/browse/CB-11297
>> 3. Can't execute JavaScript code in the background. There are several
>> issues related to this. See
>> https://issues.apache.org/jira/browse/CB-12815
>> 4. XmlHttpRequests don't work, because of Cross-Origin Resource
>> Sharing issue (CORS). There is a workaround plugin created by Oracle
>> (UPL licensed, which is Apache-2.0 compatible). See
>> https://issues.apache.org/jira/browse/CB-10143
>> 5. Migration of localStorage from UIWebView. There is a migration
>> plugin available. See https://issues.apache.org/jira/browse/CB-11974
>>
>> Of course there are several bugs also that need to be resolved. List
>> here: https://s.apache.org/QfsF
>>
>> Out of the 5 issues, 3 (external) plugins are available for the
>> issues, 2 require minor code changes.
>>
>> For a solution to issue 5, I am proposing a proxy webview engine
>> plugin that will:
>> 1. Read a preference to use a particular webview engine
>> 2. Proxy the selected webview engine's interface from its interface
>>
>> This proxy will possibly help with migration and testing, so users can
>> "beta test" WKWebView now for existing apps (and switch back if there
>> are problems). This is like a "feature flag" that I mentioned before,
>> but at runtime, for users.
>>
>> This proxy webview engine plugin can also possibly help with
>> InAppBrowser, I'm not sure (since that plugin has more hooks into a
>> webview's interface).
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward

[Jan Piotrowski]

> - How do people know in which of the numerous Cordova repos to create
> their issues (especially bad for tooling)

As Julio already indicated this is a communication problem, that we
can solve by having a page at issues.cordova.io. Pages like
https://cordova.apache.org/contribute/ also have links to JIRA now,
this should then be of course adapted as well, complete with an
explanation how to find the correct issue list to create a new one.

The problem of people just _using_ the wrong place can't really be
solved, but we will have to find a way to deal with them. One option
is to use something like https://github-issue-mover.appspot.com/ to
fix what users mess up. Another way is to be very strict with closing
issues and pointing people in the right direction (which users usually
don't like at all though).

For Cordova tooling I expect no one outside of the developers to
really know what happens where - but if I see it correctly we almost
don't have any tooling JIRA issues as well, right?

> - How to manage meta-issues that concern more than one repo

That is indeed a problem that Github hasn't solved yet (afaik). One
can of course create individual issues, then mention the parent issue
there to create an automatic link between the issues.

> (Can we
> productively use whatever tools GitHub provides here, or will we have to
> get permission from INFRA for every little thing we do?)

Which tools do you refer to? External Kanban tool or something similar?
In general we are just Members of the Github repos and don't have any
power to change settings etc - Admin is only Apache, which means
INFRA.

2018-08-02 16:51 GMT+02:00  :
> There is much I don't like about JIRA and in general I prefer GitHub
> issues. However, there's issues that did came up during previous
> discussions of this topic, and that have no proper solution that I know of
>
>- How do people know in which of the numerous Cordova repos to create
>their issues (especially bad for tooling)
>- How to manage meta-issues that concern more than one repo (Can we
>productively use whatever tools GitHub provides here, or will we have to
>get permission from INFRA for every little thing we do?)
>
> I fear that if we blindly rush into this, all we will get is an even more
> fragmented landscape of issues and discussions
>
> Am Do., 2. Aug. 2018 um 16:34 Uhr schrieb Jan Piotrowski <
> piotrow...@gmail.com>:
>
>> Decision making for Apache projects is described here:
>> https://community.apache.org/committers/decisionMaking.html
>>
>> So to make it official:
>> I hereby declare that I will start implementing the stuff from my
>> initial email if nobody objects in the next 72 hours (meaning: before
>> next Monday). After that I will create the INFRA issue.
>>
>> The other, preliminary taks can already be started - I did by creating
>> 2 cordova-docs issues that I already linked. For the rest of b) I will
>> probably start another mailing list thread.
>>
>> 2018-08-02 15:35 GMT+02:00 Chris Brody :
>> > What will it take to take care of a) Enable GitHub issues on all
>> > repositories via INFRA ticket?
>> >
>> > I think this is needed really badly. There are way too many cases of
>> > questions and issues being raised in the wrong place, lost in diverse
>> > discussion forums, or not even asked at all.
>> > On Wed, Aug 1, 2018 at 9:59 AM Bryan Ellis 
>> wrote:
>> >>
>> >> +1
>> >>
>> >> Not sure if (f) was a task, as in to find a way to integrate GH and
>> Slack, but it does exist.
>> >>
>> >> https://slack.github.com/ <https://slack.github.com/>
>> >>
>> >> It covers a lot including new commits, pr, new issues, code reviews,
>> and more.
>> >>
>> >>
>> >> > On Aug 1, 2018, at 22:22, Jan Piotrowski 
>> wrote:
>> >> >
>> >> > Another one:
>> >> >
>> >> > f) Find and activate way for Github issue (and PR) updates to be
>> >> > posted so Slack #issues
>> >> >
>> >> > 2018-07-31 18:14 GMT+02:00 Jan Piotrowski :
>> >> >> The npm forum solves a very different problem for npm - they had too
>> >> >> much noise in Github issues because of the project's popularity. Too
>> >> >> much popularity is not one of Cordova's problems ;)
>> >> >>
>> >> >> Many uses of cordova-discuss will be able to move to the individual
>> >> >> project repositories issues, maybe we can even think about getting
>> rid
>> >&g

Re: WKWebView plugin - issues before baking it in to cordova-ios

[Jan Piotrowski]

Couldn't the class names be changed when integrating the plugin?
Because the console stuff is still messing with people :/

2018-08-02 17:01 GMT+02:00 Shazron :
> yup, the class name conflict is unavoidable -- it's like when we
> integrated the console plugin.
>
> The bridge plugin will be able to load any webview engine plugin that
> has already been installed, not just the main 2. I didn't want to
> confuse people with too much information, since this is not an Ionic
> blog post.
> On Thu, Aug 2, 2018 at 10:50 PM julio cesar sanchez
>  wrote:
>>
>> As long as we don't break pluggable webviews, I don't think it's needed,
>> there are other wkwebview plugins (from telerik, oracle, etc).
>>
>> But as some (or all) of them started as forks, there will be probably
>> problems with duplicate class names.
>>
>> 2018-08-02 16:42 GMT+02:00 Jan Piotrowski :
>>
>> > Many Cordova users out there are probably using
>> > https://github.com/ionic-team/cordova-plugin-ionic-webview. Does this
>> > play any role in regards to the blog post? Should this maybe be
>> > mentioned as an anticipated question?
>> >
>> > 2018-08-02 16:31 GMT+02:00 Shazron :
>> > > Please review the draft of the blog post about this:
>> > > "The Future of the iOS WebView in Apache Cordova"
>> > > https://github.com/apache/cordova-docs/pull/867
>> > > On Mon, Jul 16, 2018 at 2:38 PM Shazron  wrote:
>> > >>
>> > >> I've done with my review with all the issues that need to resolved
>> > >> with the plugin before it can be baked in to the platform for a major
>> > >> version release. I'm going to discuss issues with respect to migration
>> > >> of developers from UIWebView (features that will be lost or are
>> > >> different)
>> > >>
>> > >> 1. Cookies don't persist. This is a WebKit bug, but someone has
>> > >> created a plugin for a workaround. See
>> > >> https://issues.apache.org/jira/browse/CB-12074
>> > >> 2. Can't delete cookies. This is/was a WebKit bug (2015), need to test
>> > >> for the iOS 11/12. See https://issues.apache.org/jira/browse/CB-11297
>> > >> 3. Can't execute JavaScript code in the background. There are several
>> > >> issues related to this. See
>> > >> https://issues.apache.org/jira/browse/CB-12815
>> > >> 4. XmlHttpRequests don't work, because of Cross-Origin Resource
>> > >> Sharing issue (CORS). There is a workaround plugin created by Oracle
>> > >> (UPL licensed, which is Apache-2.0 compatible). See
>> > >> https://issues.apache.org/jira/browse/CB-10143
>> > >> 5. Migration of localStorage from UIWebView. There is a migration
>> > >> plugin available. See https://issues.apache.org/jira/browse/CB-11974
>> > >>
>> > >> Of course there are several bugs also that need to be resolved. List
>> > >> here: https://s.apache.org/QfsF
>> > >>
>> > >> Out of the 5 issues, 3 (external) plugins are available for the
>> > >> issues, 2 require minor code changes.
>> > >>
>> > >> For a solution to issue 5, I am proposing a proxy webview engine
>> > >> plugin that will:
>> > >> 1. Read a preference to use a particular webview engine
>> > >> 2. Proxy the selected webview engine's interface from its interface
>> > >>
>> > >> This proxy will possibly help with migration and testing, so users can
>> > >> "beta test" WKWebView now for existing apps (and switch back if there
>> > >> are problems). This is like a "feature flag" that I mentioned before,
>> > >> but at runtime, for users.
>> > >>
>> > >> This proxy webview engine plugin can also possibly help with
>> > >> InAppBrowser, I'm not sure (since that plugin has more hooks into a
>> > >> webview's interface).
>> > >
>> > > -
>> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> > > For additional commands, e-mail: dev-h...@cordova.apache.org
>> > >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> > For additional commands, e-mail: dev-h...@cordova.apache.org
>> >
>> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Re: WKWebView plugin - issues before baking it in to cordova-ios

[Jan Piotrowski]

That would be really great. Thanks!

2018-08-02 17:16 GMT+02:00 Shazron :
> We could -- I can just add a suffix or prefix...
> On Thu, Aug 2, 2018 at 11:14 PM Jan Piotrowski  wrote:
>>
>> Couldn't the class names be changed when integrating the plugin?
>> Because the console stuff is still messing with people :/
>>
>> 2018-08-02 17:01 GMT+02:00 Shazron :
>> > yup, the class name conflict is unavoidable -- it's like when we
>> > integrated the console plugin.
>> >
>> > The bridge plugin will be able to load any webview engine plugin that
>> > has already been installed, not just the main 2. I didn't want to
>> > confuse people with too much information, since this is not an Ionic
>> > blog post.
>> > On Thu, Aug 2, 2018 at 10:50 PM julio cesar sanchez
>> >  wrote:
>> >>
>> >> As long as we don't break pluggable webviews, I don't think it's needed,
>> >> there are other wkwebview plugins (from telerik, oracle, etc).
>> >>
>> >> But as some (or all) of them started as forks, there will be probably
>> >> problems with duplicate class names.
>> >>
>> >> 2018-08-02 16:42 GMT+02:00 Jan Piotrowski :
>> >>
>> >> > Many Cordova users out there are probably using
>> >> > https://github.com/ionic-team/cordova-plugin-ionic-webview. Does this
>> >> > play any role in regards to the blog post? Should this maybe be
>> >> > mentioned as an anticipated question?
>> >> >
>> >> > 2018-08-02 16:31 GMT+02:00 Shazron :
>> >> > > Please review the draft of the blog post about this:
>> >> > > "The Future of the iOS WebView in Apache Cordova"
>> >> > > https://github.com/apache/cordova-docs/pull/867
>> >> > > On Mon, Jul 16, 2018 at 2:38 PM Shazron  wrote:
>> >> > >>
>> >> > >> I've done with my review with all the issues that need to resolved
>> >> > >> with the plugin before it can be baked in to the platform for a major
>> >> > >> version release. I'm going to discuss issues with respect to 
>> >> > >> migration
>> >> > >> of developers from UIWebView (features that will be lost or are
>> >> > >> different)
>> >> > >>
>> >> > >> 1. Cookies don't persist. This is a WebKit bug, but someone has
>> >> > >> created a plugin for a workaround. See
>> >> > >> https://issues.apache.org/jira/browse/CB-12074
>> >> > >> 2. Can't delete cookies. This is/was a WebKit bug (2015), need to 
>> >> > >> test
>> >> > >> for the iOS 11/12. See https://issues.apache.org/jira/browse/CB-11297
>> >> > >> 3. Can't execute JavaScript code in the background. There are several
>> >> > >> issues related to this. See
>> >> > >> https://issues.apache.org/jira/browse/CB-12815
>> >> > >> 4. XmlHttpRequests don't work, because of Cross-Origin Resource
>> >> > >> Sharing issue (CORS). There is a workaround plugin created by Oracle
>> >> > >> (UPL licensed, which is Apache-2.0 compatible). See
>> >> > >> https://issues.apache.org/jira/browse/CB-10143
>> >> > >> 5. Migration of localStorage from UIWebView. There is a migration
>> >> > >> plugin available. See https://issues.apache.org/jira/browse/CB-11974
>> >> > >>
>> >> > >> Of course there are several bugs also that need to be resolved. List
>> >> > >> here: https://s.apache.org/QfsF
>> >> > >>
>> >> > >> Out of the 5 issues, 3 (external) plugins are available for the
>> >> > >> issues, 2 require minor code changes.
>> >> > >>
>> >> > >> For a solution to issue 5, I am proposing a proxy webview engine
>> >> > >> plugin that will:
>> >> > >> 1. Read a preference to use a particular webview engine
>> >> > >> 2. Proxy the selected webview engine's interface from its interface
>> >> > >>
>> >> > >> This proxy will possibly help with migration and testing, so users 
>> >> > >> can
>> >> > >> "beta test&qu

Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward

[Jan Piotrowski]

Created INFRA issue at https://issues.apache.org/jira/browse/INFRA-16876


2018-08-02 17:29 GMT+02:00  :
>>
>> For Cordova tooling I expect no one outside of the developers to
>>
> really know what happens where - but if I see it correctly we almost
>> don't have any tooling JIRA issues as well, right?
>>
> There's plenty tooling related JIRA issues. And rightly so.
>
> IMHO, joining all tooling packages in a mono-repo might be beneficial for
> this and other problems. But that is something for another day.
>
> That is indeed a problem that Github hasn't solved yet (afaik). One
>> can of course create individual issues, then mention the parent issue
>> there to create an automatic link between the issues.
>>
>> > (Can we
>> > productively use whatever tools GitHub provides here, or will we have to
>> > get permission from INFRA for every little thing we do?)
>>
>> Which tools do you refer to? External Kanban tool or something similar?
>> In general we are just Members of the Github repos and don't have any
>> power to change settings etc - Admin is only Apache, which means
>> INFRA.
>>
> I was thinking of "Projects". I saw them on the team level. Don't really
> know what they do though.
> But basically I was speaking hypothetically. Hoping someone with experience
> of that kind of GitHub usage would chime in.

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

Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward

[Jan Piotrowski]

That worked, the ticket was just resolved and issues are now enabled
for all repos (beside cordova-weinre which is archived):

https://github.com/apache/cordova-android/issues
https://github.com/apache/cordova-ios/issues
https://github.com/apache/cordova-plugin-inappbrowser/issues
...

On to b), c) etc.

2018-08-06 13:09 GMT+02:00 Chris Brody :
> On Mon, Aug 6, 2018 at 6:48 AM Jan Piotrowski  wrote:
>>
>> Created INFRA issue at https://issues.apache.org/jira/browse/INFRA-16876
>
> +100
>
> -
> 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] Delete apache/cordova-fauxton-server repository?

[Jan Piotrowski]

During enabling of issues and removing of "Mirror of ..." on our
Github repos INFRA noticed that we have a repo without any content
(issues, history, ...):

https://github.com/apache/cordova-fauxton-server

I will ask INFRA to remove/delete this repo at the end of the week if
there are no objections.

-J

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

Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward

[Jan Piotrowski]

You may have noticed the first issues coming in on some repositories.

1. In hindsight enabling issues for deprecated platforms, plugins etc
may not have been the smartest decision. We will have to find out how
to handle this - we should probably write down a "deprecation /
archivation policy" anyway.

2. Some people are missing the "all tickets in one view" interface. I
quickly built http://cordova.betamo.de/ as a workaround.
The second link on there generates a few prepared Github search links,
including one that is valid for _all_ Cordova repositories:
https://github.com/issues?q=type%3Aissue+repo%3Aapache%2Fcordova-android+repo%3Aapache%2Fcordova-ios+repo%3Aapache%2Fcordova-windows+repo%3Aapache%2Fcordova-browser+repo%3Aapache%2Fcordova-osx+repo%3Aapache%2Fcordova-test-platform+repo%3Aapache%2Fcordova-electron+repo%3Aapache%2Fcordova-blackberry+repo%3Aapache%2Fcordova-firefoxos+repo%3Aapache%2Fcordova-ubuntu+repo%3Aapache%2Fcordova-wp8+repo%3Aapache%2Fcordova-tizen+repo%3Aapache%2Fcordova-qt+repo%3Aapache%2Fcordova-webos+repo%3Aapache%2Fcordova-amazon-fireos+repo%3Aapache%2Fcordova-wp7+repo%3Aapache%2Fcordova-bada+repo%3Aapache%2Fcordova-bada-wac+repo%3Aapache%2Fcordova-plugin-battery-status+repo%3Aapache%2Fcordova-plugin-camera+repo%3Aapache%2Fcordova-plugin-device+repo%3Aapache%2Fcordova-plugin-dialogs+repo%3Aapache%2Fcordova-plugin-file+repo%3Aapache%2Fcordova-plugin-geolocation+repo%3Aapache%2Fcordova-plugin-inappbrowser+repo%3Aapache%2Fcordova-plugin-media+repo%3Aapache%2Fcordova-plugin-media-capture+repo%3Aapache%2Fcordova-plugin-network-information+repo%3Aapache%2Fcordova-plugin-screen-orientation+repo%3Aapache%2Fcordova-plugin-splashscreen+repo%3Aapache%2Fcordova-plugin-statusbar+repo%3Aapache%2Fcordova-plugin-vibration+repo%3Aapache%2Fcordova-plugin-whitelist+repo%3Aapache%2Fcordova-plugin-wkwebview-engine+repo%3Aapache%2Fcordova-plugins+repo%3Aapache%2Fcordova-plugin-console+repo%3Aapache%2Fcordova-plugin-contacts+repo%3Aapache%2Fcordova-plugin-device-motion+repo%3Aapache%2Fcordova-plugin-device-orientation+repo%3Aapache%2Fcordova-plugin-file-transfer+repo%3Aapache%2Fcordova-plugin-globalization+repo%3Aapache%2Fcordova-plugin-legacy-whitelist+repo%3Aapache%2Fcordova-cli+repo%3Aapache%2Fcordova-plugman+repo%3Aapache%2Fcordova-coho+repo%3Aapache%2Fcordova-js+repo%3Aapache%2Fcordova-lib+repo%3Aapache%2Fcordova-common+repo%3Aapache%2Fcordova-create+repo%3Aapache%2Fcordova-fetch+repo%3Aapache%2Fcordova-serve+repo%3Aapache%2Fcordova-plugin-test-framework+repo%3Aapache%2Fcordova-paramedic+repo%3Aapache%2Fcordova-mobile-spec+repo%3Aapache%2Fcordova-app-hello-world+repo%3Aapache%2Fcordova-template-reference+repo%3Aapache%2Fcordova-docs+repo%3Aapache%2Fcordova-status+repo%3Aapache%2Fcordova-discuss+repo%3Aapache%2Fcordova-apache-board-reports+repo%3Aapache%2Fcordova-new-committer-and-pmc+repo%3Aapache%2Fcordova-node-xcode+repo%3Aapache%2Fcordova-medic+repo%3Aapache%2Fcordova-labs+repo%3Aapache%2Fcordova-weinre+repo%3Aapache%2Fcordova-app-harness+repo%3Aapache%2Fcordova-plugin-compat+repo%3Aapache%2Fcordova-registry-web+repo%3Aapache%2Fcordova-registry+repo%3Aapache%2Fcordova-fauxton-server&s=created&type=Issues
Nice, isn't it?
Do you have any specific requests for filters or interface you need or
want? What did you use in JIRA that you couldn't find for Github?
Shouldn't be too hard to whip something up.

-J




2018-08-06 16:05 GMT+02:00 Jan Piotrowski :
> That worked, the ticket was just resolved and issues are now enabled
> for all repos (beside cordova-weinre which is archived):
>
> https://github.com/apache/cordova-android/issues
> https://github.com/apache/cordova-ios/issues
> https://github.com/apache/cordova-plugin-inappbrowser/issues
> ...
>
> On to b), c) etc.
>
> 2018-08-06 13:09 GMT+02:00 Chris Brody :
>> On Mon, Aug 6, 2018 at 6:48 AM Jan Piotrowski  wrote:
>>>
>>> Created INFRA issue at https://issues.apache.org/jira/browse/INFRA-16876
>>
>> +100
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>

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

Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward

[Jan Piotrowski]

Please open a new discussion re the archiving/deprecation topic - this
is a very different thing.

Sure, feel free to transfer the links to a Github Wiki or whatever -
as I wanted to generate the links automatically I had to use a
scripting language.

2018-08-07 17:07 GMT+02:00 Chris Brody :
> I would favor archiving the deprecated repos asap so we don't have to
> deal with traffic on those anymore.
>
> Thanks for making the nice GitHub filter and group repo links. I would
> really favor using a wiki, which is supported by GitHub, for this kind
> of thing for the sake of easy writing & editing.
>
> Really nice!
> On Tue, Aug 7, 2018 at 11:01 AM Jan Piotrowski  wrote:
>>
>> You may have noticed the first issues coming in on some repositories.
>>
>> 1. In hindsight enabling issues for deprecated platforms, plugins etc
>> may not have been the smartest decision. We will have to find out how
>> to handle this - we should probably write down a "deprecation /
>> archivation policy" anyway.
>>
>> 2. Some people are missing the "all tickets in one view" interface. I
>> quickly built http://cordova.betamo.de/ as a workaround.
>> The second link on there generates a few prepared Github search links,
>> including one that is valid for _all_ Cordova repositories:
>> https://github.com/issues?q=type%3Aissue+repo%3Aapache%2Fcordova-android+repo%3Aapache%2Fcordova-ios+repo%3Aapache%2Fcordova-windows+repo%3Aapache%2Fcordova-browser+repo%3Aapache%2Fcordova-osx+repo%3Aapache%2Fcordova-test-platform+repo%3Aapache%2Fcordova-electron+repo%3Aapache%2Fcordova-blackberry+repo%3Aapache%2Fcordova-firefoxos+repo%3Aapache%2Fcordova-ubuntu+repo%3Aapache%2Fcordova-wp8+repo%3Aapache%2Fcordova-tizen+repo%3Aapache%2Fcordova-qt+repo%3Aapache%2Fcordova-webos+repo%3Aapache%2Fcordova-amazon-fireos+repo%3Aapache%2Fcordova-wp7+repo%3Aapache%2Fcordova-bada+repo%3Aapache%2Fcordova-bada-wac+repo%3Aapache%2Fcordova-plugin-battery-status+repo%3Aapache%2Fcordova-plugin-camera+repo%3Aapache%2Fcordova-plugin-device+repo%3Aapache%2Fcordova-plugin-dialogs+repo%3Aapache%2Fcordova-plugin-file+repo%3Aapache%2Fcordova-plugin-geolocation+repo%3Aapache%2Fcordova-plugin-inappbrowser+repo%3Aapache%2Fcordova-plugin-media+repo%3Aapache%2Fcordova-plugin-media-capture+repo%3Aapache%2Fcordova-plugin-network-information+repo%3Aapache%2Fcordova-plugin-screen-orientation+repo%3Aapache%2Fcordova-plugin-splashscreen+repo%3Aapache%2Fcordova-plugin-statusbar+repo%3Aapache%2Fcordova-plugin-vibration+repo%3Aapache%2Fcordova-plugin-whitelist+repo%3Aapache%2Fcordova-plugin-wkwebview-engine+repo%3Aapache%2Fcordova-plugins+repo%3Aapache%2Fcordova-plugin-console+repo%3Aapache%2Fcordova-plugin-contacts+repo%3Aapache%2Fcordova-plugin-device-motion+repo%3Aapache%2Fcordova-plugin-device-orientation+repo%3Aapache%2Fcordova-plugin-file-transfer+repo%3Aapache%2Fcordova-plugin-globalization+repo%3Aapache%2Fcordova-plugin-legacy-whitelist+repo%3Aapache%2Fcordova-cli+repo%3Aapache%2Fcordova-plugman+repo%3Aapache%2Fcordova-coho+repo%3Aapache%2Fcordova-js+repo%3Aapache%2Fcordova-lib+repo%3Aapache%2Fcordova-common+repo%3Aapache%2Fcordova-create+repo%3Aapache%2Fcordova-fetch+repo%3Aapache%2Fcordova-serve+repo%3Aapache%2Fcordova-plugin-test-framework+repo%3Aapache%2Fcordova-paramedic+repo%3Aapache%2Fcordova-mobile-spec+repo%3Aapache%2Fcordova-app-hello-world+repo%3Aapache%2Fcordova-template-reference+repo%3Aapache%2Fcordova-docs+repo%3Aapache%2Fcordova-status+repo%3Aapache%2Fcordova-discuss+repo%3Aapache%2Fcordova-apache-board-reports+repo%3Aapache%2Fcordova-new-committer-and-pmc+repo%3Aapache%2Fcordova-node-xcode+repo%3Aapache%2Fcordova-medic+repo%3Aapache%2Fcordova-labs+repo%3Aapache%2Fcordova-weinre+repo%3Aapache%2Fcordova-app-harness+repo%3Aapache%2Fcordova-plugin-compat+repo%3Aapache%2Fcordova-registry-web+repo%3Aapache%2Fcordova-registry+repo%3Aapache%2Fcordova-fauxton-server&s=created&type=Issues
>> Nice, isn't it?
>> Do you have any specific requests for filters or interface you need or
>> want? What did you use in JIRA that you couldn't find for Github?
>> Shouldn't be too hard to whip something up.
>>
>> -J
>>
>>
>>
>>
>> 2018-08-06 16:05 GMT+02:00 Jan Piotrowski :
>> > That worked, the ticket was just resolved and issues are now enabled
>> > for all repos (beside cordova-weinre which is archived):
>> >
>> > https://github.com/apache/cordova-android/issues
>> > https://github.com/apache/cordova-ios/issues
>> > https://github.com/apache/cordova-plugin-inappbrowser/issues
>> > ...
>> >
>> > On to b), c) etc.
>> >
>> > 2018-08-06 13:09 GMT+02:00 Chris Brody :
>> >> On Mon, Aug 6, 2018 at 6:48 AM Jan Piotrowsk

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

[Jan Piotrowski]

Now that Github Issues are enabled on all repositories, it makes sense
to create a (or several) new Issue and PR template(s) that doesn't
point to JIRA any more and also uses the current state of the art.

Current Cordova issue and PR template:
- no issue template
- 
https://github.com/apache/cordova-android/blob/master/.github/PULL_REQUEST_TEMPLATE.md


1. Issue template:

Github supports multiple issue templates for some time now, which
first lets users choose what type of issue they want to create:
https://help.github.com/articles/about-issue-and-pull-request-templates/

The template selection can look like this:
https://github.com/fastlane/fastlane/issues/new/choose
https://github.com/babel/babel/issues/new/choose

I think we should definitely use this for Bug Report, Feature Request,
Support Question. What sections should we suggest in our templates?

Here are some additinal issue templates from around the web:
https://github.com/stevemao/github-issue-templates/tree/master/emoji-guide
https://github.com/devspace/awesome-github-templates


2. Pull Request template:

I think we can drop the JIRA/issue requirement from the checklist
completely - as a PR on Github is always the starting point of code
changes now. If there is an (Github) issue the PR resolves, it should
of course be linked (`closes #123` or similar), but this is not a
requirement.

Similar about commit message conventions - I don't think we need an
issue ID in there as all code changes will be done via PRs which via
"squash + merge" will include PR ID in the commit message (again
fastlane as an example:
https://github.com/fastlane/fastlane/commits/master)

I would suggest we use something similar to this, which explicitly
asks for running the tests and writing documentation:
https://github.com/fastlane/fastlane/blob/master/.github/PULL_REQUEST_TEMPLATE.md

What do you think regarding PR template?


3. Merge Conventions / Protected Branch:

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

What do you think about this suggestion?


Did I miss anything that is connected to these 3 topics?

-J

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

Re: Dealing with deprecated repos

[Jan Piotrowski]

What is the current (probably unwritten) rule regarding deprecation
and archival of Cordova repositories?

-J

2018-08-07 17:16 GMT+02:00 Chris Brody :
> Continuation of discussion from
> https://lists.apache.org/thread.html/affbc74f0ff4d34bc09657c3c302e185cc98b946d260184847fdf191@%3Cdev.cordova.apache.org%3E
>
> I think it is not desired to actively support deprecated repos. I
> think the easiest solution is to simply make those repos archived.
>
> But what if there are people still using the deprecated repos who are
> motivated to take them over?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

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

[Jan Piotrowski]

Thanks all, but handling the migration of JIRA issues to Github is
not really the topic of this discussion.
Either use the other "[DISCUSS] [JIRA -> GitHub Issues] The way
forward" thread where I had defined this as "d) Define and execute
issue migration from JIRA to GitHub" or create a new thread.
Thank you.

Any feedback about the 3 topics I mentioned in my initial email in this thread?

J

2018-08-07 19:45 GMT+02:00 julio cesar sanchez :
> I wouldn't do 2, most people won't create a new issue, but that doesn't
> mean the issue doesn't exist.
>
> Anyway, I think there is another thread about the migration, this is for
> the templates.
>
>
> El mar., 7 ago. 2018 a las 19:04, Chris Brody ()
> escribió:
>
>> Options I can think of:
>>
>> 1: make and use an auto-migration script
>> 2: use quick filters to close issues in bulk with a message that the
>> OP should manually raise on GitHub if so desired
>> 3: continue with JIRA issues for a while
>>
>> I would vote for the easiest way possible to end use of JIRA issues
>> (probably option 2).
>> On Tue, Aug 7, 2018 at 12:59 PM gandhi rajan 
>> wrote:
>> >
>> > Hi Jan,
>> >
>> > I like your suggestions. But curious to understand how to take care of
>> > existing issues which are currently available in JIRA? Should it be
>> ported
>> > to respective git repos or will continue to remain as is till it's
>> closed?
>> >
>> > On Tuesday, August 7, 2018, Jan Piotrowski  wrote:
>> >
>> > > Now that Github Issues are enabled on all repositories, it makes sense
>> > > to create a (or several) new Issue and PR template(s) that doesn't
>> > > point to JIRA any more and also uses the current state of the art.
>> > >
>> > > Current Cordova issue and PR template:
>> > > - no issue template
>> > > - https://github.com/apache/cordova-android/blob/master/.
>> > > github/PULL_REQUEST_TEMPLATE.md
>> > >
>> > >
>> > > 1. Issue template:
>> > >
>> > > Github supports multiple issue templates for some time now, which
>> > > first lets users choose what type of issue they want to create:
>> > >
>> https://help.github.com/articles/about-issue-and-pull-request-templates/
>> > >
>> > > The template selection can look like this:
>> > > https://github.com/fastlane/fastlane/issues/new/choose
>> > > https://github.com/babel/babel/issues/new/choose
>> > >
>> > > I think we should definitely use this for Bug Report, Feature Request,
>> > > Support Question. What sections should we suggest in our templates?
>> > >
>> > > Here are some additinal issue templates from around the web:
>> > >
>> https://github.com/stevemao/github-issue-templates/tree/master/emoji-guide
>> > > https://github.com/devspace/awesome-github-templates
>> > >
>> > >
>> > > 2. Pull Request template:
>> > >
>> > > I think we can drop the JIRA/issue requirement from the checklist
>> > > completely - as a PR on Github is always the starting point of code
>> > > changes now. If there is an (Github) issue the PR resolves, it should
>> > > of course be linked (`closes #123` or similar), but this is not a
>> > > requirement.
>> > >
>> > > Similar about commit message conventions - I don't think we need an
>> > > issue ID in there as all code changes will be done via PRs which via
>> > > "squash + merge" will include PR ID in the commit message (again
>> > > fastlane as an example:
>> > > https://github.com/fastlane/fastlane/commits/master)
>> > >
>> > > I would suggest we use something similar to this, which explicitly
>> > > asks for running the tests and writing documentation:
>> > > https://github.com/fastlane/fastlane/blob/master/.github/
>> > > PULL_REQUEST_TEMPLATE.md
>> > >
>> > > What do you think regarding PR template?
>> > >
>> > >
>> > > 3. Merge Conventions / Protected Branch:
>> > >
>> > > Connected to all that is my suggestion to protect the `master` branch
>> > > so that by default nobody can commit there - all changes have to be
>> > > made via Pull Requests. Pull Requests are by default merged via the
>> > > "Squash + Merge" button / functionality so that all commits are
>>

Re: [DISCUSS] Cordova idea: integrate with fastlane?

[Jan Piotrowski]

What exactly do you mean by "integrate"?

Apps built with Cordova (and Ionic) are pretty well supported by
Fastlane, /platforms/ios|android are just native projects after all -
even though you have to take some extra measures to handle the
generated projects. I wrote some articles about how can work:
https://ionic.zone/fastlane

J



2018-08-07 21:38 GMT+02:00 Chris Brody :
> Should we explore this idea for Android & iOS?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

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

[Jan Piotrowski]

All very good points Chris.

>> > 3. Merge Conventions / Protected Branch:

> Nice idea. The one exception is that committers sometimes have to tag
> and push individual commits when making releases.

We will definitely have to check how this works with current workflows
defined in coho and in other places.

> I would favor a place where a contributor can mark if s/he would
> recommend the committer should *not* use the squash option.

That of course could be defined in the contributor guidelines or PR
template (although there it might be a bit confusing to new users that
don't know what this is talking about). Do you know how other project
handle that?
In the end it is always the decision of the committer how contributed
code makes it into the code base, so having good guidelines for us
would probably be the best solution, right?

-J

2018-08-07 21:36 GMT+02:00 Chris Brody :
>> 1. Issue template:
>> [...]
>> I think we should definitely use this for Bug Report, Feature Request,
>> Support Question. What sections should we suggest in our templates?
>
> All suggestions look good, should probably give proper attribution.
>
>> 2. Pull Request template:
>>
>> I think we can drop the JIRA/issue requirement from the checklist
>> completely - as a PR on Github is always the starting point of code
>> changes now. If there is an (Github) issue the PR resolves, it should
>> of course be linked (`closes #123` or similar), but this is not a
>> requirement.
>>
>> Similar about commit message conventions - I don't think we need an
>> issue ID in there as all code changes will be done via PRs which via
>> "squash + merge" will include PR ID in the commit message (again
>> fastlane as an example:
>> https://github.com/fastlane/fastlane/commits/master)
>>
>> I would suggest we use something similar to this, which explicitly
>> asks for running the tests and writing documentation:
>> https://github.com/fastlane/fastlane/blob/master/.github/PULL_REQUEST_TEMPLATE.md
>>
>> What do you think regarding PR template?
>
> Looks nice in general, again we should probably give proper
> attribution upon reuse.
>
> It might be good to require a checkbox for developers certificate of
> origin (developercertificate.org) like at:
> https://github.com/papercss/papercss/blob/master/.github/PULL_REQUEST_TEMPLATE.md
>
>> 3. Merge Conventions / Protected Branch:
>>
>> Connected to all that is my suggestion to protect the `master` branch
>> so that by default nobody can commit there - all changes have to be
>> made via Pull Requests.
>
> Nice idea. The one exception is that committers sometimes have to tag
> and push individual commits when making releases.
>
> A possible workaround would be to say that we always start a release
> branch before publishing an actual release, like they seem to do in
> Node.js. Could keep things a little cleaner.
>
>> Pull Requests are by default merged via the
>> "Squash + Merge" button / functionality so that all commits are
>> squashed into one clean commit per change. This also enforces the
>> commit message structure I posted above. (Of course committers can
>> choose to _not_ use Squash + Merge if appropriate for the PR - e.g.
>> when cherry picking commits from a release branch or similar).
>
> I would favor a place where a contributor can mark if s/he would
> recommend the committer should *not* use the squash option.
>
> I am starting to favor a choice between squash merge and merge commit.
> I think these choices keep things a little more clear in the history
> and would reliably mark the PR, unlike "rebase merge".
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Re: [DISCUSS] Cordova idea: integrate with fastlane?

[Jan Piotrowski]

Fastlane itself currently doesn't mention Cordova in its documentation
and setup creation at all - there are Github issues to change that -
so this probably would not be really appropriate as we ask for "tools"
etc to have _proper_ Cordova support and documentation how to use it.

But yes, I think fastlane could be beneficial for many Cordova users,
especially in corporations and enterprises.

Another interesting aspect of fastlane it that it uses fastlane itself
to build, test, create releases etc. It built itself something like
our `cordova-coho`. That could be worth investigating (one day) as it
really works well.

-J

2018-08-07 22:54 GMT+02:00 Chris Brody :
> Nice, especialy about ionic.zone/fastlane. Shouldn't we feature
> fastlane on cordova.io?
> On Tue, Aug 7, 2018 at 4:03 PM Jan Piotrowski  wrote:
>>
>> What exactly do you mean by "integrate"?
>>
>> Apps built with Cordova (and Ionic) are pretty well supported by
>> Fastlane, /platforms/ios|android are just native projects after all -
>> even though you have to take some extra measures to handle the
>> generated projects. I wrote some articles about how can work:
>> https://ionic.zone/fastlane
>>
>> J
>>
>>
>>
>> 2018-08-07 21:38 GMT+02:00 Chris Brody :
>> > Should we explore this idea for Android & iOS?
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> > For additional commands, e-mail: dev-h...@cordova.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Re: [DISCUSS] Cordova idea: integrate with fastlane?

[Jan Piotrowski]

Full agreement Jesse.
(Although I generally think Cordova users would benefit from more
links to useful tooling - but this should be discussed somewhere else)

Just for the record: fastlane is not a hosted service, but just
another tool you install locally.
Some CI providers offer it on their service as it is simpler than to
build all the mobile automation manually.

(Disclosure: I am a contributor at fastlane)

2018-08-07 23:58 GMT+02:00 Jesse :
> Don't forget:
> https://docs.microsoft.com/en-us/appcenter/
> https://build.phonegap.com/
> https://www.buddybuild.com/features/ci-cd-integrations
>
> If they ask to be featured, then sure, lets, but I don't think we need to
> be chasing them.
> A simple cordova blog post explaining how to get cordova working with
> fastlane, et al would be great.
>
>
>
>
>
> @purplecabbage
> risingj.com
>
> On Tue, Aug 7, 2018 at 2:17 PM, Jan Piotrowski  wrote:
>
>> Fastlane itself currently doesn't mention Cordova in its documentation
>> and setup creation at all - there are Github issues to change that -
>> so this probably would not be really appropriate as we ask for "tools"
>> etc to have _proper_ Cordova support and documentation how to use it.
>>
>> But yes, I think fastlane could be beneficial for many Cordova users,
>> especially in corporations and enterprises.
>>
>> Another interesting aspect of fastlane it that it uses fastlane itself
>> to build, test, create releases etc. It built itself something like
>> our `cordova-coho`. That could be worth investigating (one day) as it
>> really works well.
>>
>> -J
>>
>> 2018-08-07 22:54 GMT+02:00 Chris Brody :
>> > Nice, especialy about ionic.zone/fastlane. Shouldn't we feature
>> > fastlane on cordova.io?
>> > On Tue, Aug 7, 2018 at 4:03 PM Jan Piotrowski 
>> wrote:
>> >>
>> >> What exactly do you mean by "integrate"?
>> >>
>> >> Apps built with Cordova (and Ionic) are pretty well supported by
>> >> Fastlane, /platforms/ios|android are just native projects after all -
>> >> even though you have to take some extra measures to handle the
>> >> generated projects. I wrote some articles about how can work:
>> >> https://ionic.zone/fastlane
>> >>
>> >> J
>> >>
>> >>
>> >>
>> >> 2018-08-07 21:38 GMT+02:00 Chris Brody :
>> >> > Should we explore this idea for Android & iOS?
>> >> >
>> >> > -
>> >> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> >> > For additional commands, e-mail: dev-h...@cordova.apache.org
>> >> >
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> >> For additional commands, e-mail: dev-h...@cordova.apache.org
>> >>
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> > For additional commands, e-mail: dev-h...@cordova.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>

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

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

[Jan Piotrowski]

Update to my initial email:

I just noticed we actually _do_ have an issue template in use in the
cordovs-docs repository:
https://github.com/apache/cordova-docs/blob/master/.github/ISSUE_TEMPLATE.md

J

2018-08-07 23:18 GMT+02:00 julio cesar sanchez :
> I think us as committers should decide if the commits make sense to keep
> all of them or squash them into one. But bug fixes should usually be only
> one commit, and major refactors are not usually sent by non committers
>
> El El mar, 7 ago 2018 a las 23:02, Chris Brody 
> escribió:
>
>> > > I would favor a place where a contributor can mark if s/he would
>> > > recommend the committer should *not* use the squash option.
>> >
>> > That of course could be defined in the contributor guidelines or PR
>> > template (although there it might be a bit confusing to new users that
>> > don't know what this is talking about). Do you know how other project
>> > handle that?
>>
>> Haven't seen anything like this before.
>>
>> > In the end it is always the decision of the committer how contributed
>> > code makes it into the code base, so having good guidelines for us
>> > would probably be the best solution, right?
>>
>> Yes. General common sense may prove to be the major principle, as I
>> think it has in the past. For example:
>> * Someone raises a PR with bug fixes and major refactoring in separate
>> commits (should not be squashed)
>> * Someone else raises a PR with a single fix, but with extra commits
>> to fix issues with the first commit (*should* be squashed)
>>
>> I wonder if we can track these discussions in a better way, somehow. I
>> have no time to help with these things right now. I think better
>> tracking could help ensure these important tasks do not get forgotten.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>

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

Re: Dealing with deprecated repos

[Jan Piotrowski]

Let me play devil's advocate:

Archiving means disabling everything - issues, PRs, etc.
Don't we want to let people create PRs with bug fixes or changes (we
may or may not choose to merge) for other people to benefit from?

-J

2018-08-08 3:40 GMT+02:00 Gearóid M :
> +1 on archiving deprecated repos, it's an easy way to make it very clear that 
> it is no longer maintained
>
> On Wed, 8 Aug 2018, at 01:37, Chris Brody wrote:
>> +1
>> On Tue, Aug 7, 2018 at 11:32 AM julio cesar sanchez
>>  wrote:
>> >
>> > Archived repos are read only.
>> >
>> > People can still clone and/or fork them, they just can't send PRs or create
>> > new issues.
>> >
>> > I'm +1 on archiving them.
>> >
>> >
>> >
>> > El mar., 7 ago. 2018 a las 17:25,  escribió:
>> >
>> > > I suggest archiving them all and deal with any issues as they appear. 
>> > > After
>> > > all, repos can be unarchived if necessary.
>> > >
>> > > Chris Brody  schrieb am Di., 7. Aug. 2018, 17:16:
>> > >
>> > > > Continuation of discussion from
>> > > >
>> > > >
>> > > https://lists.apache.org/thread.html/affbc74f0ff4d34bc09657c3c302e185cc98b946d260184847fdf191@%3Cdev.cordova.apache.org%3E
>> > > >
>> > > > I think it is not desired to actively support deprecated repos. I
>> > > > think the easiest solution is to simply make those repos archived.
>> > > >
>> > > > But what if there are people still using the deprecated repos who are
>> > > > motivated to take them over?
>> > > >
>> > > > -
>> > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> > > > For additional commands, e-mail: dev-h...@cordova.apache.org
>> > > >
>> > > >
>> > >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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

Re: [DISCUSS] [JIRA -> GitHub Issues] The way forward

[Jan Piotrowski]

> 1. Should we just disable those then? One other way is to add in bold
> big letters about the deprecation in the New Issue template

We should probably "just" define our deprecation and archival policy
(see other active thread). Depending on that, we can create another
INFRA issue to get taken care of that. There is no flood of Github
issues for these repos right now, so no harm done.

> 2. These links are super useful. Perhaps they should be on the
> website, what do you all think? Not sure if the scripting for the
> second link is server side or it could be client side as well (via
> JavaScript). Perhaps on the https://cordova.apache.org/contribute/
> (contribute.cordova.io) page. That massive github link could also be
> auto-generated as well on that page, somehow. Let me know how I can
> help.

Yes, I think those could very well be on the Cordova web site as well.
http://cordova.betamo.de/ is built with PHP, I will put its source up
on Github later so someone can rebuild it with JS if needed/wanted.
For now it is just a solution for us committers (and especially
myself).

-J

2018-08-08 5:34 GMT+02:00 Shazron :
> Thanks Jan!
>
> 1. Should we just disable those then? One other way is to add in bold
> big letters about the deprecation in the New Issue template
> 2. These links are super useful. Perhaps they should be on the
> website, what do you all think? Not sure if the scripting for the
> second link is server side or it could be client side as well (via
> JavaScript). Perhaps on the https://cordova.apache.org/contribute/
> (contribute.cordova.io) page. That massive github link could also be
> auto-generated as well on that page, somehow. Let me know how I can
> help.
> On Tue, Aug 7, 2018 at 11:01 PM Jan Piotrowski  wrote:
>>
>> You may have noticed the first issues coming in on some repositories.
>>
>> 1. In hindsight enabling issues for deprecated platforms, plugins etc
>> may not have been the smartest decision. We will have to find out how
>> to handle this - we should probably write down a "deprecation /
>> archivation policy" anyway.
>>
>> 2. Some people are missing the "all tickets in one view" interface. I
>> quickly built http://cordova.betamo.de/ as a workaround.
>> The second link on there generates a few prepared Github search links,
>> including one that is valid for _all_ Cordova repositories:
>> https://github.com/issues?q=type%3Aissue+repo%3Aapache%2Fcordova-android+repo%3Aapache%2Fcordova-ios+repo%3Aapache%2Fcordova-windows+repo%3Aapache%2Fcordova-browser+repo%3Aapache%2Fcordova-osx+repo%3Aapache%2Fcordova-test-platform+repo%3Aapache%2Fcordova-electron+repo%3Aapache%2Fcordova-blackberry+repo%3Aapache%2Fcordova-firefoxos+repo%3Aapache%2Fcordova-ubuntu+repo%3Aapache%2Fcordova-wp8+repo%3Aapache%2Fcordova-tizen+repo%3Aapache%2Fcordova-qt+repo%3Aapache%2Fcordova-webos+repo%3Aapache%2Fcordova-amazon-fireos+repo%3Aapache%2Fcordova-wp7+repo%3Aapache%2Fcordova-bada+repo%3Aapache%2Fcordova-bada-wac+repo%3Aapache%2Fcordova-plugin-battery-status+repo%3Aapache%2Fcordova-plugin-camera+repo%3Aapache%2Fcordova-plugin-device+repo%3Aapache%2Fcordova-plugin-dialogs+repo%3Aapache%2Fcordova-plugin-file+repo%3Aapache%2Fcordova-plugin-geolocation+repo%3Aapache%2Fcordova-plugin-inappbrowser+repo%3Aapache%2Fcordova-plugin-media+repo%3Aapache%2Fcordova-plugin-media-capture+repo%3Aapache%2Fcordova-plugin-network-information+repo%3Aapache%2Fcordova-plugin-screen-orientation+repo%3Aapache%2Fcordova-plugin-splashscreen+repo%3Aapache%2Fcordova-plugin-statusbar+repo%3Aapache%2Fcordova-plugin-vibration+repo%3Aapache%2Fcordova-plugin-whitelist+repo%3Aapache%2Fcordova-plugin-wkwebview-engine+repo%3Aapache%2Fcordova-plugins+repo%3Aapache%2Fcordova-plugin-console+repo%3Aapache%2Fcordova-plugin-contacts+repo%3Aapache%2Fcordova-plugin-device-motion+repo%3Aapache%2Fcordova-plugin-device-orientation+repo%3Aapache%2Fcordova-plugin-file-transfer+repo%3Aapache%2Fcordova-plugin-globalization+repo%3Aapache%2Fcordova-plugin-legacy-whitelist+repo%3Aapache%2Fcordova-cli+repo%3Aapache%2Fcordova-plugman+repo%3Aapache%2Fcordova-coho+repo%3Aapache%2Fcordova-js+repo%3Aapache%2Fcordova-lib+repo%3Aapache%2Fcordova-common+repo%3Aapache%2Fcordova-create+repo%3Aapache%2Fcordova-fetch+repo%3Aapache%2Fcordova-serve+repo%3Aapache%2Fcordova-plugin-test-framework+repo%3Aapache%2Fcordova-paramedic+repo%3Aapache%2Fcordova-mobile-spec+repo%3Aapache%2Fcordova-app-hello-world+repo%3Aapache%2Fcordova-template-reference+repo%3Aapache%2Fcordova-docs+repo%3Aapache%2Fcordova-status+repo%3Aapache%2Fcordova-discuss+repo%3Aapache%2Fcordova-apache-board-reports+repo%3Aapache%2Fcordova-new-committer-and-pmc+repo%3Aapache%2Fcordova-node-xcode+repo%3Aapache%2Fcordova-medic+repo%3Aapache%2Fcordova-labs+repo%3Aapache%2Fcordova-weinre+repo%3Aapache%2Fcordova-app-harness+repo%3Aapache%2Fcordov

Re: Dealing with deprecated repos

[Jan Piotrowski]

Great, then this seems to be Cordova's deprecation policy. Write it
down, publish it, link to it from the deprecated projects so users
know about it - problem solved.

Just to be on the safe side: Was this previously discussed and decided?

-J

2018-08-08 10:49 GMT+02:00 julio cesar sanchez :
> No, when we deprecate something it means no more work will be done on it.
>
> Triaging issues, reviewing and merging other people prs and continuing
> doing releases it’s work. We aren’t supposed to do anything else when we
> deprecate.
>
> People can freely create and maintain a fork, but it won’t be official and
> won’t live in the Apache repo.
>
>
> El miércoles, 8 de agosto de 2018, Jan Piotrowski 
> escribió:
>
>> Let me play devil's advocate:
>>
>> Archiving means disabling everything - issues, PRs, etc.
>> Don't we want to let people create PRs with bug fixes or changes (we
>> may or may not choose to merge) for other people to benefit from?
>>
>> -J
>>
>> 2018-08-08 3:40 GMT+02:00 Gearóid M :
>> > +1 on archiving deprecated repos, it's an easy way to make it very clear
>> that it is no longer maintained
>> >
>> > On Wed, 8 Aug 2018, at 01:37, Chris Brody wrote:
>> >> +1
>> >> On Tue, Aug 7, 2018 at 11:32 AM julio cesar sanchez
>> >>  wrote:
>> >> >
>> >> > Archived repos are read only.
>> >> >
>> >> > People can still clone and/or fork them, they just can't send PRs or
>> create
>> >> > new issues.
>> >> >
>> >> > I'm +1 on archiving them.
>> >> >
>> >> >
>> >> >
>> >> > El mar., 7 ago. 2018 a las 17:25,  escribió:
>> >> >
>> >> > > I suggest archiving them all and deal with any issues as they
>> appear. After
>> >> > > all, repos can be unarchived if necessary.
>> >> > >
>> >> > > Chris Brody  schrieb am Di., 7. Aug. 2018,
>> 17:16:
>> >> > >
>> >> > > > Continuation of discussion from
>> >> > > >
>> >> > > >
>> >> > > https://lists.apache.org/thread.html/affbc74f0ff4d34bc09657c3c302e1
>> 85cc98b946d260184847fdf191@%3Cdev.cordova.apache.org%3E
>> >> > > >
>> >> > > > I think it is not desired to actively support deprecated repos. I
>> >> > > > think the easiest solution is to simply make those repos archived.
>> >> > > >
>> >> > > > But what if there are people still using the deprecated repos who
>> are
>> >> > > > motivated to take them over?
>> >> > > >
>> >> > > > 
>> -
>> >> > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> >> > > > For additional commands, e-mail: dev-h...@cordova.apache.org
>> >> > > >
>> >> > > >
>> >> > >
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> >> For additional commands, e-mail: dev-h...@cordova.apache.org
>> >>
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> > For additional commands, e-mail: dev-h...@cordova.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>

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

Re: Dealing with deprecated repos

[Jan Piotrowski]

Please note that this part of the discussion with me playing devil's
advocate - I pretty much agree with what you are saying.

Is there any way users can find out about new forks of deprecated
repos? Fork network view on Github maybe? Then adding a link to that
in the deprecation notice would be a nice move.

Any other comments regarding a possible "Cordova Deprecation Policy"
than what Julio already wrote?

-J


2018-08-08 11:52 GMT+02:00 julio cesar sanchez :
> This is the deprecation policy from cordova-plugin-contacts
>
> Deprecation Notice
> This plugin is being deprecated. No more work will be done on this plugin
> by the Cordova development community. You can continue to use this plugin
> and it should work as-is in the future but any more arising issues will not
> be fixed by the Cordova community.
>
> All the deprecated repos have a similar deprecation notice.
>
> Other than that, I don't think we have something more official. Also, I
> don't know were/if that message was discussed.
>
> What I said on my previous message is my interpretation of "work", for me
> what I said is work, not sure if everybody agrees on that, and it's not
> official, just my opinion. Also my opinion of Cordova Community is
> everybody who wants to contribute, not just the committers.
>
> We have dozens of repos and hundreds of open PRs that we aren't able to
> manage, so keeping the deprecated repos open for issues/PRs in case
> somebody want to fix something will just bring frustration to those people
> as their PRs won't be reviewed/merged. And if we plan on continuing
> reviewing/merging on deprecated repos, why did we deprecate them on the
> first place?
>
> El mié., 8 ago. 2018 a las 11:26, Jan Piotrowski ()
> escribió:
>
>> Great, then this seems to be Cordova's deprecation policy. Write it
>> down, publish it, link to it from the deprecated projects so users
>> know about it - problem solved.
>>
>> Just to be on the safe side: Was this previously discussed and decided?
>>
>> -J
>>
>> 2018-08-08 10:49 GMT+02:00 julio cesar sanchez :
>> > No, when we deprecate something it means no more work will be done on it.
>> >
>> > Triaging issues, reviewing and merging other people prs and continuing
>> > doing releases it’s work. We aren’t supposed to do anything else when we
>> > deprecate.
>> >
>> > People can freely create and maintain a fork, but it won’t be official
>> and
>> > won’t live in the Apache repo.
>> >
>> >
>> > El miércoles, 8 de agosto de 2018, Jan Piotrowski 
>> > escribió:
>> >
>> >> Let me play devil's advocate:
>> >>
>> >> Archiving means disabling everything - issues, PRs, etc.
>> >> Don't we want to let people create PRs with bug fixes or changes (we
>> >> may or may not choose to merge) for other people to benefit from?
>> >>
>> >> -J
>> >>
>> >> 2018-08-08 3:40 GMT+02:00 Gearóid M :
>> >> > +1 on archiving deprecated repos, it's an easy way to make it very
>> clear
>> >> that it is no longer maintained
>> >> >
>> >> > On Wed, 8 Aug 2018, at 01:37, Chris Brody wrote:
>> >> >> +1
>> >> >> On Tue, Aug 7, 2018 at 11:32 AM julio cesar sanchez
>> >> >>  wrote:
>> >> >> >
>> >> >> > Archived repos are read only.
>> >> >> >
>> >> >> > People can still clone and/or fork them, they just can't send PRs
>> or
>> >> create
>> >> >> > new issues.
>> >> >> >
>> >> >> > I'm +1 on archiving them.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > El mar., 7 ago. 2018 a las 17:25,  escribió:
>> >> >> >
>> >> >> > > I suggest archiving them all and deal with any issues as they
>> >> appear. After
>> >> >> > > all, repos can be unarchived if necessary.
>> >> >> > >
>> >> >> > > Chris Brody  schrieb am Di., 7. Aug.
>> 2018,
>> >> 17:16:
>> >> >> > >
>> >> >> > > > Continuation of discussion from
>> >> >> > > >
>> >> >> > > >
>> >> >> > >
>> https://lists.apache.org/thread.html/affbc74f0ff4d34bc09657c3c302e1
>> >> 85cc98b946d2601848

Re: Dealing with deprecated repos

[Jan Piotrowski]

> I wouldn't point to a fork, because that will mean we have to search for
> the forks and decide which one is better. Also in case we want to do that,
> we should do it before archiving. If a better fork appears after archiving
> we won't be able to change.
>
> I think best option is to point to network tab of github (in case people
is
> not aware of it). There you can see all forks available and easily spot
> extra commits people has done in an easy and visually way.

Sorry if that was not clear, this is exactly what I meant. The standard
deprecation notice text should include a general link to /network of the
repo with some appropriate language and explanation how to look for forks.


2018-08-08 12:23 GMT+02:00 julio cesar sanchez :

> I wouldn't point to a fork, because that will mean we have to search for
> the forks and decide which one is better. Also in case we want to do that,
> we should do it before archiving. If a better fork appears after archiving
> we won't be able to change.
>
> I think best option is to point to network tab of github (in case people is
> not aware of it). There you can see all forks available and easily spot
> extra commits people has done in an easy and visually way.
> Example for contacts plugin
> https://github.com/apache/cordova-plugin-contacts/network
> You can see there is a fork from timholbrook that added 22 commits from
> latest release, and then this fork has a few other forks itself with some
> other extra commits.
>
> El mié., 8 ago. 2018 a las 12:15, Shazron () escribió:
>
> > Let's make it formal with what we had in the repo, perhaps a new page
> > or section in the docs somewhere.
> > On Wed, Aug 8, 2018 at 6:09 PM Jan Piotrowski 
> > wrote:
> > >
> > > Please note that this part of the discussion with me playing devil's
> > > advocate - I pretty much agree with what you are saying.
> > >
> > > Is there any way users can find out about new forks of deprecated
> > > repos? Fork network view on Github maybe? Then adding a link to that
> > > in the deprecation notice would be a nice move.
> > >
> > > Any other comments regarding a possible "Cordova Deprecation Policy"
> > > than what Julio already wrote?
> > >
> > > -J
> > >
> > >
> > > 2018-08-08 11:52 GMT+02:00 julio cesar sanchez  >:
> > > > This is the deprecation policy from cordova-plugin-contacts
> > > >
> > > > Deprecation Notice
> > > > This plugin is being deprecated. No more work will be done on this
> > plugin
> > > > by the Cordova development community. You can continue to use this
> > plugin
> > > > and it should work as-is in the future but any more arising issues
> > will not
> > > > be fixed by the Cordova community.
> > > >
> > > > All the deprecated repos have a similar deprecation notice.
> > > >
> > > > Other than that, I don't think we have something more official.
> Also, I
> > > > don't know were/if that message was discussed.
> > > >
> > > > What I said on my previous message is my interpretation of "work",
> for
> > me
> > > > what I said is work, not sure if everybody agrees on that, and it's
> not
> > > > official, just my opinion. Also my opinion of Cordova Community is
> > > > everybody who wants to contribute, not just the committers.
> > > >
> > > > We have dozens of repos and hundreds of open PRs that we aren't able
> to
> > > > manage, so keeping the deprecated repos open for issues/PRs in case
> > > > somebody want to fix something will just bring frustration to those
> > people
> > > > as their PRs won't be reviewed/merged. And if we plan on continuing
> > > > reviewing/merging on deprecated repos, why did we deprecate them on
> the
> > > > first place?
> > > >
> > > > El mié., 8 ago. 2018 a las 11:26, Jan Piotrowski (<
> > piotrow...@gmail.com>)
> > > > escribió:
> > > >
> > > >> Great, then this seems to be Cordova's deprecation policy. Write it
> > > >> down, publish it, link to it from the deprecated projects so users
> > > >> know about it - problem solved.
> > > >>
> > > >> Just to be on the safe side: Was this previously discussed and
> > decided?
> > > >>
> > > >> -J
> > > >>
> > > >> 2018-08-08 10:49 GMT+02:00 julio cesar sanchez 

Re: Dealing with deprecated repos

[Jan Piotrowski]

+1

cordova.apache.org/contribute/deprecation_policy.html
 maybe?
Should include summary of what was discussed here, and best also the
deprecation notice template in markdown for copy paste.

-J

2018-08-08 12:55 GMT+02:00 Shazron :

> Formal as in this is our policy. From what Julio Cesar Sanchez said
> earlier:
> "This is the deprecation policy from cordova-plugin-contacts
>
> Deprecation Notice
> This plugin is being deprecated. No more work will be done on this plugin
> by the Cordova development community. You can continue to use this plugin
> and it should work as-is in the future but any more arising issues will not
> be fixed by the Cordova community.
>
> All the deprecated repos have a similar deprecation notice."
>
> As to where, we just make a new page, say deprecationpolicy.html or
> something, and link it from the Contribute page (as a suggestion). If
> we run into this again, we point to the policy.
> On Wed, Aug 8, 2018 at 6:33 PM Chris Brody  wrote:
> >
> > On Wed, Aug 8, 2018 at 6:15 AM Shazron  wrote:
> > >
> > > Let's make it formal with what we had in the repo
> >
> > Does this mean make the archiving process formal or make something else
> formal?
> >
> > What kind of repo?
> >
> > > or section in the docs somewhere.
> >
> > The question is always where?
> >
> > On Wed, Aug 8, 2018 at 6:24 AM julio cesar sanchez
> >  wrote:
> > >
> > > I wouldn't point to a fork, because that will mean we have to search
> for
> > > the forks and decide which one is better.
> >
> > +1
> >
> > > If a better fork appears after archiving
> > > we won't be able to change.
> >
> > I think someone else made the point that we can always unarchive in
> > case of need. I suspect (and hope) we should be able to unarchive on a
> > temporary basis then re-archive.
> >
> > > I think best option is to point to network tab of github (in case
> people is
> >
> > +1
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Major Cordova release idea

[Jan Piotrowski]

You are talking about Cordova CLI, correct?

Do you only want to release a new CLI or also the other stuff?

What about the platforms - major or minor releases?
What about core plugins - major or minor releases?

Maybe I misunderstood, but why rush all this instead of just do the work in
all the repo's `master`, then release when the actual platforms and plugins
are ready, then do a CLI release when justified?

-J



2018-08-08 13:42 GMT+02:00 Chris Brody :

> I would like to propose the following idea: make a major Cordova
> release (Cordova 9), based on what was already published for Cordova
> 8, with a very limited set of changes such as:
> * drop Node.js 4 support
> * remove committed node_modules from all supported Cordova platforms
> * commit package-lock.json
> * update dependencies (should resolve the npm audit issues if done right)
> * drop support for Xcode pre-9 on both iOS and cordova-osx
>
> and maybe some other items such as:
> * cordova-android patch release discussed in the thread at:
> https://bit.ly/2vpUbSS
> * add iOS bridge WebView as proposed in
> https://github.com/apache/cordova-docs/pull/867
> * drop iOS pre-10 support
>
> This idea should give us a double benefit:
> * drop burden of old Node.js 4, Xcode pre-9, and maybe iOS pre-10
> support almost immediately
> * less pressure to cut a major release off the master branches
>
> This would entail making a new release branch per repo, sometimes
> based on master and sometimes based on another release branch, and
> then increasing to the subsequent major release -dev version on
> master.
>
> I will probably need 1-2 weeks to finish something for a client then
> can work on this one.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

[DISCUSS] [Github Issues] Issue and Pull Request labels

[Jan Piotrowski]

Now that we have Github issues enabled for all our repositories,
another new thing we have to talk about are Github Issue and Pull
Request labels.


If you are not aware of Github labels, here is a nice introduction:
https://help.github.com/articles/about-labels/

This also contains a list of the default labels all our repositories
got when issues were enabled:

> bug, duplicate, good first issue, help wanted, invalid, question, wontfix

https://help.github.com/articles/about-labels/#using-default-labels

Issues also have a color, which - when chosen well and used uniform
across repositories - make it easier to scan the issue list.


As we come from JIRA, it's important to understand the differences.
A JIRA ticket has many different fields: Type, Status, Priority,
Resolution, Affects Version/s, Fix Version/s, Component/s, Labels,
Security Level, Environment, Estimate, Flag, External issue URL,
External issue ID, Epic Link, Sprint, Docs Text
On Github none of those exist. Most of this information has to be
supplied via the description of the issue (and can be requested via
the issue or PR template, see previous email), but it can also make
sense to map some of those via Github labels.


With the first few issues that came in on our repositories, I already
created the following two new labels:

- `support` - Used for support questions that don't report a bug and
don't request a new feature but e.g. want to understand how something
works, need help debugging their individual problem etc. (This will
probably be the majority of the issue we are getting.)
- `platform: android` (ios, browser, windows, osx) - For plugin
repositories it makes sense to categorize e.g. a bug report or feature
request for its platform


Other projects have very structured labels:
https://github.com/fastlane/fastlane/labels
https://github.com/ionic-team/ionic-cli/labels

Or pretty extensive lists of stuff:
https://github.com/Microsoft/TypeScript/labels
https://github.com/Microsoft/vscode/labels

What do we actually need for the beginning?
Any other input?


Does anyone have an idea how we can "manage" our labels across our ~70
repositories? Are there any scripts out there that can automate the
creation/deletion of them via the Github API?


Best,
Jan

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