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

2020-08-31 Thread 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: đź’ˇCordova as a monorepo - ??

2020-08-28 Thread 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: [VOTE] Unarchive & Un-deprecate cordova-plugin-file-transfer

2020-08-18 Thread 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: [VOTE] Unarchive & Un-deprecate cordova-plugin-device-motion

2020-08-18 Thread 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-device-orientation

2020-08-18 Thread 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: [PROPOSAL] Enable Probot Apps to Improve Issue Tracker

2020-04-17 Thread 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: Team page on Cordova website

2020-04-02 Thread 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: [GitHub] [cordova-eslint] raphinesse opened a new pull request #10: feat: make base rules stricter & closer to semistandard

2019-11-10 Thread Jan Piotrowski
This repository is misconfigured, these emails should probably go to the
commits mailing list and not dev. (Yep, the default in the infra tool is
not optimal here)

J

Am Fr., 8. Nov. 2019 um 21:05 Uhr schrieb GitBox :

> raphinesse opened a new pull request #10: feat: make base rules stricter &
> closer to semistandard
> URL: https://github.com/apache/cordova-eslint/pull/10
>
>
>This removes all exceptions from `semistandard` we had in place, except
>for `camelcase: off`. This step had already been taken in some of our
>repos (e.g. `cordova-js`, `cordova-common`) before.
>
>`camelcase` stays disabled for now as enabling & enforcing it would have
>the potential of creating many conflicts with existing work in progress.
>
> 
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>
> With regards,
> Apache Git Services
>
> -
> 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

2019-08-13 Thread Jan Piotrowski
Best create a new one, as it has been quite some time and we probably
don't want everyone have to read these 13 mails again.

(You have my +1)

J

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

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



Re: [DISCUSS] Replacing ADB usage in favour for using BundleTools

2019-08-12 Thread Jan Piotrowski
Sounds great. Historically we always had trouble when Google decided
to replace/deprecate/change any of the tools in the build toolchain,
so keeping up to date what is the tool of the week sounds like a good
idea.

Important to consider is the availability of that tool for older
Android versions, on CI providers etc. But I expect that to be part of
the implementation work.

-J

Am Mo., 12. Aug. 2019 um 14:34 Uhr schrieb Norman Breau
:
>
> Hi all,
>
> Just throwing a potential idea out there, maybe for the cordova-android
> 9.x milestone. Now that we have android bundle support merged into
> master, I think it is worth considering to incorporate bundletool, which
> is a command line toolset for managing and manipulating AAB files. It is
> the underlying command tool that Google uses for Gradle, Android Studio,
> and Google Play service. It is released under the Apache license. I
> believe it can for the most part replace ADB usage, because it can both
> build apks, and deploy apks to device.
>
> One benefit this will provide us is we can then support the cordova run
> command while using bundles since the bundletool itself can install apk
> generated from the bundle to a connected device.
>
> I think there might be some cases where using the ADB executable is
> still necessary, perhaps for listing devices, etc. But for actual
> building/installing a build to the device, I believe ADB can be replaced
> with the bundletool.
>
> We can still provide an APK to those end-users who still wants to use
> APKs for deployment as we can extract APKs from a bundle.
>
> I'll provide couple links for reference:
> https://developer.android.com/studio/command-line/bundletool
>
> https://github.com/google/bundletool
>
> - Norman
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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



Re: [Cordova dev] info needed label

2019-07-30 Thread Jan Piotrowski
You created and merged
https://github.com/apache/cordova-contribute/pull/32 which contains
wrong information. Please undo it.

One random example where the previously existing `question` label is
missing as it was renamed to `info-needed` which does not match the
>20 issues and PRs it was used before. This is why you never rename an
existing label to something else with a different meaning. Please undo
it here and in all other repositories where you did that.

I don't know where else you renamed or removed any labels as there is
no changelog for this information after the fact, so please go through
them all (listed on apache/cordova) and undo it on all of them.

If you don't agree with the common usage of question as a label, feel
free to open a discussion about this _after fixing this_.

J

Am Di., 30. Juli 2019 um 16:02 Uhr schrieb Chris Brody :
>
> I have changed the "query" labels back to "question". I continue to
> think we should avoid using the "question" label since I have seen it
> used for both real questions and cases where more information is
> needed from the OP.
>
> Here are the "question" issues on all of our repos:
>
> * https://github.com/apache/cordova-cli/labels/question
> * https://github.com/apache/cordova-fetch/labels/question
> * https://github.com/apache/cordova-plugin-file/labels/question
> * https://github.com/apache/cordova-plugin-inappbrowser/labels/question
> * https://github.com/apache/cordova-plugin-media-capture/labels/question
> * https://github.com/apache/cordova-plugin-statusbar/labels/question
> * https://github.com/apache/cordova-windows/labels/question
>
> Over and out,
>
> Chris
>
> On Tue, Jul 30, 2019 at 9:50 AM Chris Brody  wrote:
> >
> > I am now changing the "query" labels back to "question", though under
> > protest. I did already check that the new "info-needed" label is used
> > where it looked appropriate. But I don't see what documentation
> > changes have to be "undone".
> >
> > On Tue, Jul 30, 2019 at 5:57 AM Jan Piotrowski  wrote:
> > >
> > > Chris, it has been another week and I still see `query` issue labels
> > > that should be `question`, and I have to assume some are also still
> > > `info needed` and thus used in a conflicting way to their previous
> > > usage. Documentation changes are also not undone.
> > >
> > > Please finally undo this.
> > >
> > > -J
> > >
> > > Am Mi., 24. Juli 2019 um 08:20 Uhr schrieb Jan Piotrowski
> > > :
> > > >
> > > > Chris, it has been over a week. What is the state of undoing the label
> > > > and documentation changes?
> > > >
> > > > -J
> > > >
> > > > Am Mi., 17. Juli 2019 um 20:08 Uhr schrieb Jan Piotrowski
> > > > :
> > > > >
> > > > > By renaming the label, you also renamed it for all existing issues.
> > > > > Now many labels that were just questions of users (both open and
> > > > > closed) indicate that info is needed - which might be true or not.
> > > > >
> > > > > Please undo all renaming of labels, both to `info-needed` and `query`.
> > > > > Please undo the changes to the label documentation as well.
> > > > >
> > > > > On the other hand, we all seem to agree that a new additional
> > > > > `info-needed` is valid and needed, so to create that and document it
> > > > > is totally fine.
> > > > >
> > > > > It takes some additional effort to maintain labels like this (as you
> > > > > of course want to remove it after the user replied), but as I assume
> > > > > one/you would only apply the label when also asking for the
> > > > > information, you should get a GitHub notification and be able to take
> > > > > care of that when reading the response.
> > > > >
> > > > > Regarding the "question" label, I understand what you mean, but don't
> > > > > agree. But that is a topic for a new thread then where we can
> > > > > elaborate.
> > > > >
> > > > > -J
> > > > >
> > > > >
> > > > > Am Mi., 17. Juli 2019 um 18:47 Uhr schrieb Chris Brody 
> > > > > :
> > > > > >
> > > > > > This work was not done 100% correctly, please accept my apologies.
> > > > > >
> > > > > > I will try to explain why it was not done 100% correctly so we c

Re: Android - App Bundle Support

2019-07-30 Thread Jan Piotrowski
+1 on #1, #2 and #3 - just don't forget to create the issue that makes
sure #3 will be taken care of later.

J

Am Di., 30. Juli 2019 um 14:10 Uhr schrieb Norman Breau
:
>
> Hello devs!
>
> I am writing to gather feedback on the new feature to support building
> the new android packaging format: android bundles. Below are the links
> to the PRs, but I'll try to provide a brief summary below, then I'll
> provide my personal opinion.
>
> Feature PR: https://github.com/apache/cordova-android/pull/764
> Documentation PR: https://github.com/apache/cordova-docs/pull/1009
>
> What invoked moving the discussion here is the use of the packageType
> property/command line argument. During the course of the PR, it was
> decided to mimic the iOS platform use of the packageType build.json
> property to decide whether to build an APK or a AAB (bundle) file. It
> was then found that for iOS, the packageType build property is a
> property mostly related to signing and therefore, the documentation for
> this is under "Signing an App".
>
> For android, building either the APK or a bundle has no relation to
> signing, all other build.json properties available for android is a
> "signing" property. Because of this, the android documentation for
> build.json properties is also organized under a "Signing an App"
> section. As you might have guess, the addition of a new packageType
> property for android, a property that is more of a "building" property
> rather than a "signing" property makes it a little awkward to simply add
> to the current documentation without some major reorganizing.
>
> So what requires discussion is:
>
> 1) Should android reuse packageType, even if the purpose is slightly
> different for iOS?
>
> 2) If the answer to #1 is "yes", how should the android documentation be
> reorganized as to not hide a "build" property under a "Signing an App"
> section?
>
> 3) If #2 is answered yes, should this re-organizing be deferred to a
> future PR to get app bundle support out as soon as possible?
>
> Below now is how I would favour proceeding
>
> The answer to #1, should be "yes" because the metaphor I think applies
> just as well for Android as it does for iOS. While iOS as I understand,
> all packageTypes builds an IPA file, they are just signed differently,
> and to be consumed differenetly based on the selected packageType. As
> for Android, a packageType will build their own different formats, but
> they are still packages, just formatted to be  differently to be
> consumed differently, based on their packageType.
>
> Thus leading to question #2, I think a "Building the app" section should
> be added, which will mimic the format of the existing "Signing the app"
> section, but will only include properties or flags related to building
> the app. I have provided an example at
> https://github.com/apache/cordova-docs/pull/1009#issuecomment-512227371
>
> Leading to #3, another contributor have suggested to simply add the
> documentation for app bundles in the current documentation format (under
> "Signing the app" section) and defer adding the new build section to
> another PR. The intention for this is to get the feature out as soon as
> possible as the feature request is somewhat highly requested (Over 43
> positive responses on the initial feature request ticket). I don't
> really have a strong opinion one way or another therefore my action will
> be largely what everybody else thinks I should do here.
>
> Looking for everyones feedback,
> Thanks
>
> P.S. this is my first major contribution, I hope I didn't make this too
> long and I hoped I explained myself clearly.
>
>
> -
> 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 7.1.0

2019-07-30 Thread Jan Piotrowski
As I wrote in the initial email I am on this release.

CI is green after some work, but there are still open issues or
questions (e.g.
https://github.com/apache/cordova-windows/issues/357#issuecomment-511396401)
or solved issues waiting for feedback from the initial reporter.

J

Am Di., 30. Juli 2019 um 05:26 Uhr schrieb Chris Brody :
>
> I think this release should be made asap. Right now I have to do
> something like cordova platform add windows@6 or cordova platform add
> github:apache/cordova-windows#master to get a working Windows build
> for testing. I got some documentation updates merged to make it clear
> that it will *not* work with Visual Studio 2019.
>
> I can make this release sometime in the next 1-2 weeks if nobody else
> wants to make it.
>
> Is there anything else blocking this release?
>
> Does any other committer have time to make this release this week?
>
> On Fri, Jul 5, 2019 at 9:50 AM Tim Brust
>  wrote:
> >
> > For the lazy ppl, here is the diff:
> > https://github.com/apache/cordova-windows/compare/7.0.0...master
> > Go for it Jan! :)
> >
> > On Thu, Jul 4, 2019 at 5:51 PM Jan Piotrowski  wrote:
> >
> > > 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.
> > >
> > > (CI is currently red, so this will require some investigation.)
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> > >
> >
> > --
> > Tim Brust, Product Engineer
> >
> > tim.br...@sinnerschrader.com
> > T +49 40 398855 315
> >
> > SinnerSchrader Deutschland GmbH | SinnerSchrader Group
> > Völckersstraße 38, 22765 Hamburg, Germany
> >
> > Amtsgericht Hamburg HRB-Nr. 63663
> > Geschäftsführer: Matthias Schrader (Sprecher),
> > JĂĽrgen Alker, Dr. Axel Averdung, Holger Blank,
> > Thomas Dyckhoff, Dr. Lars Finke, Martin Gassner, Peggy Hutchinson
> >
> > BĂĽros: Berlin, Hamburg, Frankfurt a. M., MĂĽnchen, Prag
> >
> > https://www.sinnerschrader.com | NEXT AGENCY
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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



Re: [Cordova dev] info needed label

2019-07-30 Thread Jan Piotrowski
Chris, it has been another week and I still see `query` issue labels
that should be `question`, and I have to assume some are also still
`info needed` and thus used in a conflicting way to their previous
usage. Documentation changes are also not undone.

Please finally undo this.

-J

Am Mi., 24. Juli 2019 um 08:20 Uhr schrieb Jan Piotrowski
:
>
> Chris, it has been over a week. What is the state of undoing the label
> and documentation changes?
>
> -J
>
> Am Mi., 17. Juli 2019 um 20:08 Uhr schrieb Jan Piotrowski
> :
> >
> > By renaming the label, you also renamed it for all existing issues.
> > Now many labels that were just questions of users (both open and
> > closed) indicate that info is needed - which might be true or not.
> >
> > Please undo all renaming of labels, both to `info-needed` and `query`.
> > Please undo the changes to the label documentation as well.
> >
> > On the other hand, we all seem to agree that a new additional
> > `info-needed` is valid and needed, so to create that and document it
> > is totally fine.
> >
> > It takes some additional effort to maintain labels like this (as you
> > of course want to remove it after the user replied), but as I assume
> > one/you would only apply the label when also asking for the
> > information, you should get a GitHub notification and be able to take
> > care of that when reading the response.
> >
> > Regarding the "question" label, I understand what you mean, but don't
> > agree. But that is a topic for a new thread then where we can
> > elaborate.
> >
> > -J
> >
> >
> > Am Mi., 17. Juli 2019 um 18:47 Uhr schrieb Chris Brody 
> > :
> > >
> > > This work was not done 100% correctly, please accept my apologies.
> > >
> > > I will try to explain why it was not done 100% correctly so we can
> > > decide what we want to do next.
> > >
> > > In general, I have found the standard “question” label to be confusing
> > > since different repos in the wild, including Cordova repos, have used
> > > this label in different ways:
> > >
> > > * on some repos the “question” label was used to indicate that further
> > > input was needed from the author of the issue
> > > * on some other repos the “question” label was used to indicate that
> > > someone was just asking a question
> > >
> > > On those repos where the “question” label was used to indicate that
> > > further input was needed from the user, I took a shortcut and just
> > > changed the label to “info-needed”. I thought this was better than
> > > changing the label on every single issue where more info was needed.
> > >
> > > On some other repos I renamed the “question” label to “query”. I think
> > > we need either rename the label again, or completely remove this label
> > > and change the label on all issues affected.
> > >
> > > Since I have seen the “question” label used in multiple ways, I now
> > > find it confusing. At this point I would favor that we do not use the
> > > “question” label due to the potential for confusion.
> > >
> > > In cases where I renamed the “question” label to “info-needed”, I
> > > would like to propose that we do nothing else since the problem is
> > > already solved.
> > >
> > > Over and out.
> > >
> > > Chris
> > >
> > > On Wed, Jul 17, 2019 at 2:01 AM Hazem Saleh  wrote:
> > > >
> > > > I think this is an Excellent idea.
> > > >
> > > > Thanks and Best Regards
> > > >
> > > > > On Jul 15, 2019, at 11:07 PM, Chris Brody  
> > > > > wrote:
> > > > >
> > > > > We receive a number of support issues where I think we need an
> > > > > explicit label such as “info needed”, to make it clear that more
> > > > > information is needed before we can provide any support. I think we
> > > > > need to add this label to a number of repos such as apache/cordova,
> > > > > cordova-android, cordova-ios, etc.
> > > > >
> > > > > Any objections if I would add this label to some of the repos on 
> > > > > GitHub?
> > > > >
> > > > > -
> > > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >

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



Re: [Cordova dev] info needed label

2019-07-23 Thread Jan Piotrowski
Chris, it has been over a week. What is the state of undoing the label
and documentation changes?

-J

Am Mi., 17. Juli 2019 um 20:08 Uhr schrieb Jan Piotrowski
:
>
> By renaming the label, you also renamed it for all existing issues.
> Now many labels that were just questions of users (both open and
> closed) indicate that info is needed - which might be true or not.
>
> Please undo all renaming of labels, both to `info-needed` and `query`.
> Please undo the changes to the label documentation as well.
>
> On the other hand, we all seem to agree that a new additional
> `info-needed` is valid and needed, so to create that and document it
> is totally fine.
>
> It takes some additional effort to maintain labels like this (as you
> of course want to remove it after the user replied), but as I assume
> one/you would only apply the label when also asking for the
> information, you should get a GitHub notification and be able to take
> care of that when reading the response.
>
> Regarding the "question" label, I understand what you mean, but don't
> agree. But that is a topic for a new thread then where we can
> elaborate.
>
> -J
>
>
> Am Mi., 17. Juli 2019 um 18:47 Uhr schrieb Chris Brody 
> :
> >
> > This work was not done 100% correctly, please accept my apologies.
> >
> > I will try to explain why it was not done 100% correctly so we can
> > decide what we want to do next.
> >
> > In general, I have found the standard “question” label to be confusing
> > since different repos in the wild, including Cordova repos, have used
> > this label in different ways:
> >
> > * on some repos the “question” label was used to indicate that further
> > input was needed from the author of the issue
> > * on some other repos the “question” label was used to indicate that
> > someone was just asking a question
> >
> > On those repos where the “question” label was used to indicate that
> > further input was needed from the user, I took a shortcut and just
> > changed the label to “info-needed”. I thought this was better than
> > changing the label on every single issue where more info was needed.
> >
> > On some other repos I renamed the “question” label to “query”. I think
> > we need either rename the label again, or completely remove this label
> > and change the label on all issues affected.
> >
> > Since I have seen the “question” label used in multiple ways, I now
> > find it confusing. At this point I would favor that we do not use the
> > “question” label due to the potential for confusion.
> >
> > In cases where I renamed the “question” label to “info-needed”, I
> > would like to propose that we do nothing else since the problem is
> > already solved.
> >
> > Over and out.
> >
> > Chris
> >
> > On Wed, Jul 17, 2019 at 2:01 AM Hazem Saleh  wrote:
> > >
> > > I think this is an Excellent idea.
> > >
> > > Thanks and Best Regards
> > >
> > > > On Jul 15, 2019, at 11:07 PM, Chris Brody  wrote:
> > > >
> > > > We receive a number of support issues where I think we need an
> > > > explicit label such as “info needed”, to make it clear that more
> > > > information is needed before we can provide any support. I think we
> > > > need to add this label to a number of repos such as apache/cordova,
> > > > cordova-android, cordova-ios, etc.
> > > >
> > > > Any objections if I would add this label to some of the repos on GitHub?
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > > >
> > >
> > > -
> > > 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: [ANNOUNCEMENT] Plugin Releases

2019-07-22 Thread Jan Piotrowski
We had to roll back a misinformed change in
cordova-plugin-wkwebview-engine, so we have another bugfix release:

- cordova-plugin-wkwebview-engine@1.2.1




Am Do., 11. Juli 2019 um 18:02 Uhr schrieb Jan Piotrowski
:
>
> And finally the rest of the plugins:
>
> - cordova-plugin-file@6.0.2
> - cordova-plugin-geolocation@4.0.2
> - cordova-plugin-media@5.0.3
>
> - cordova-plugin-wkwebview-engine@1.2.0
> - cordova-plugin-camera@4.1.0
> - cordova-plugin-inappbrowser@3.1.0
>
> Blog post will follow when the first few users have upgraded to those
> and there are no massive problems, I will link to it here.
>
> Am Di., 2. Juli 2019 um 20:24 Uhr schrieb Jan Piotrowski 
> :
> >
> > We have just released an update to many of our plugins:
> >
> > - cordova-plugin-battery-status@2.0.3
> > - cordova-plugin-device@2.0.3
> > - cordova-plugin-dialogs@2.0.2
> > - cordova-plugin-media-capture@3.0.3
> > - cordova-plugin-network-information@2.0.2
> > - cordova-plugin-screen-orientation@3.0.2
> > - cordova-plugin-splashscreen@5.0.3
> > - cordova-plugin-statusbar@2.4.3
> > - cordova-plugin-vibration@3.1.1
> > - cordova-plugin-whitelist@1.3.4
> >
> > I'll wait with a blog post until after the remaining 6 plugins plugins
> > have also been voted on and been released, but of course these
> > releases above can be used starting now.
> >
> > Jan

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



Re: [VOTE] cordova-plugin-wkwebview-engine Bugfix Release

2019-07-22 Thread Jan Piotrowski
The vote has now closed. The results are:

Positive Binding Votes: 3
* Jesse MacFadyen
* Bryan Ellis
* Jan Piotrowski

Negative Binding Votes: 0

The vote has passed.

Thanks everyone!

Am Mo., 22. Juli 2019 um 19:51 Uhr schrieb Jesse :
>
> +1
>
> - coho verfify-archive
> - check out tag ... and ran tests
> - CI is green
>
> On Mon, Jul 22, 2019 at 2:50 AM Bryan Ellis  wrote:
>
> > +1
> >
> > * Confirmed signature & hashes with `coho verify-archive`
> > * Verified SHA match tags with `coho verify-tags`
> > * Re-created archives to ensure contents match release candidate
> > * Confirm vote tag is passing CI services.
> > * Changes are reasonable
> >
> >
> > On Sat, Jul 20, 2019 at 11:16 PM Jan Piotrowski 
> > wrote:
> >
> > > Please review and vote on the release of this plugins release
> > > by replying to this email (and keep discussion on the DISCUSS thread)
> > >
> > > The plugins have been published to dist/dev:
> > >
> > >
> > https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-wkwebview-engine-1.2.1/
> > >
> > > The packages were published from their corresponding git tags:
> > > cordova-plugin-wkwebview-engine: 1.2.1 (0f8d9f7769)
> > >
> > > Upon a successful vote I will upload the archives to dist/, upload
> > > them to npm, and post the corresponding blog post.
> > >
> > > Voting guidelines:
> > >
> > https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
> > > How to vote on a plugins release at
> > >
> > >
> > https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#voting
> > >
> > > Voting will go on for a minimum of 48 hours.
> > >
> > > I vote +1:
> > > * Ensured continuous build was green when repos were tagged
> > > * Changes make sense
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> > >
> >

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



[VOTE] cordova-plugin-wkwebview-engine Bugfix Release

2019-07-20 Thread Jan Piotrowski
Please review and vote on the release of this plugins release
by replying to this email (and keep discussion on the DISCUSS thread)

The plugins have been published to dist/dev:
https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-wkwebview-engine-1.2.1/

The packages were published from their corresponding git tags:
cordova-plugin-wkwebview-engine: 1.2.1 (0f8d9f7769)

Upon a successful vote I will upload the archives to dist/, upload
them to npm, and post the corresponding blog post.

Voting guidelines:
https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
How to vote on a plugins release at
https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#voting

Voting will go on for a minimum of 48 hours.

I vote +1:
* Ensured continuous build was green when repos were tagged
* Changes make sense

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



[DISCUSS] cordova-plugin-wkwebview-engine Bugfix Release

2019-07-17 Thread Jan Piotrowski
Does anyone have any reason to delay a cordova-plugin-wkwebview-engine release?
There is an ugly bug via one of the PRs that was merged that needs to be undone:

https://github.com/apache/cordova-plugin-wkwebview-engine/issues/105
https://github.com/apache/cordova-plugin-wkwebview-engine/pull/45
Revert PR: https://github.com/apache/cordova-plugin-wkwebview-engine/pull/107

Any outstanding patches to land?
If not, I will start the release tomorrow.

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



Re: [Cordova dev] info needed label

2019-07-17 Thread Jan Piotrowski
By renaming the label, you also renamed it for all existing issues.
Now many labels that were just questions of users (both open and
closed) indicate that info is needed - which might be true or not.

Please undo all renaming of labels, both to `info-needed` and `query`.
Please undo the changes to the label documentation as well.

On the other hand, we all seem to agree that a new additional
`info-needed` is valid and needed, so to create that and document it
is totally fine.

It takes some additional effort to maintain labels like this (as you
of course want to remove it after the user replied), but as I assume
one/you would only apply the label when also asking for the
information, you should get a GitHub notification and be able to take
care of that when reading the response.

Regarding the "question" label, I understand what you mean, but don't
agree. But that is a topic for a new thread then where we can
elaborate.

-J


Am Mi., 17. Juli 2019 um 18:47 Uhr schrieb Chris Brody :
>
> This work was not done 100% correctly, please accept my apologies.
>
> I will try to explain why it was not done 100% correctly so we can
> decide what we want to do next.
>
> In general, I have found the standard “question” label to be confusing
> since different repos in the wild, including Cordova repos, have used
> this label in different ways:
>
> * on some repos the “question” label was used to indicate that further
> input was needed from the author of the issue
> * on some other repos the “question” label was used to indicate that
> someone was just asking a question
>
> On those repos where the “question” label was used to indicate that
> further input was needed from the user, I took a shortcut and just
> changed the label to “info-needed”. I thought this was better than
> changing the label on every single issue where more info was needed.
>
> On some other repos I renamed the “question” label to “query”. I think
> we need either rename the label again, or completely remove this label
> and change the label on all issues affected.
>
> Since I have seen the “question” label used in multiple ways, I now
> find it confusing. At this point I would favor that we do not use the
> “question” label due to the potential for confusion.
>
> In cases where I renamed the “question” label to “info-needed”, I
> would like to propose that we do nothing else since the problem is
> already solved.
>
> Over and out.
>
> Chris
>
> On Wed, Jul 17, 2019 at 2:01 AM Hazem Saleh  wrote:
> >
> > I think this is an Excellent idea.
> >
> > Thanks and Best Regards
> >
> > > On Jul 15, 2019, at 11:07 PM, Chris Brody  wrote:
> > >
> > > We receive a number of support issues where I think we need an
> > > explicit label such as “info needed”, to make it clear that more
> > > information is needed before we can provide any support. I think we
> > > need to add this label to a number of repos such as apache/cordova,
> > > cordova-android, cordova-ios, etc.
> > >
> > > Any objections if I would add this label to some of the repos on GitHub?
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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



Re: [Cordova dev] info needed label

2019-07-16 Thread Jan Piotrowski
Yeah, that was wrong.

- "question" classifies an issue into a category: bug, feature,
enhancement, support, discussion, question
- "info-needed" is just a tag similar to "invalid" or "has-pr"

Please stop rolling this out to other repositories.
Please revert the change to the "Default labels" list on
https://github.com/apache/cordova-contribute/blob/master/github-labels.md
You should keep the "question" label as it was, and just add a new one.

(Your proposal spoke about "add this label" by the way, which I and
other gave a +1 - not renaming one of the default Github labels)

J

Am Di., 16. Juli 2019 um 00:00 Uhr schrieb Chris Brody :
>
> So far I renamed question -> info needed in the following (if I recall
> correctly):
>
> * apache/cordova
> * cordova-common
> * cordova-lib
> * cordova-android
> * cordova-ios
>
> and raised https://github.com/apache/cordova-contribute/pull/32
>
> I will go through the other repos in
> https://github.com/apache/cordova/issues/10 (where we discussed the
> Cordova 9 release plan).
>
> On Mon, Jul 15, 2019 at 5:28 PM julio cesar sanchez
>  wrote:
> >
> > For JIRA I think we agreed to close after 2 weeks with no response. Users
> > can reopen if they provide the info later.
>
> <3
>
> > Bonus points if you add it to
> > https://github.com/apache/cordova-contribute/blob/master/github-labels.md#custom-labels
> > and give it a nice vibrant color.
>
> Done in https://github.com/apache/cordova-contribute/pull/32 - could
> it be more creative?
>
> On Mon, Jul 15, 2019 at 2:20 PM Tim Brust  wrote:
>
> > Installing the Stale bot is probably not possible I guess?
>
> I don’t like the Stale bot so much, nice idea though.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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



Re: [Cordova dev] info needed label

2019-07-15 Thread Jan Piotrowski
The nice thing about missing process is that one can do whatever one wants ;)

+1

Bonus points if you add it to
https://github.com/apache/cordova-contribute/blob/master/github-labels.md#custom-labels
and give it a nice vibrant color.

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

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



Re: [ANNOUNCEMENT] Plugin Releases

2019-07-11 Thread Jan Piotrowski
And finally the rest of the plugins:

- cordova-plugin-file@6.0.2
- cordova-plugin-geolocation@4.0.2
- cordova-plugin-media@5.0.3

- cordova-plugin-wkwebview-engine@1.2.0
- cordova-plugin-camera@4.1.0
- cordova-plugin-inappbrowser@3.1.0

Blog post will follow when the first few users have upgraded to those
and there are no massive problems, I will link to it here.

Am Di., 2. Juli 2019 um 20:24 Uhr schrieb Jan Piotrowski :
>
> We have just released an update to many of our plugins:
>
> - cordova-plugin-battery-status@2.0.3
> - cordova-plugin-device@2.0.3
> - cordova-plugin-dialogs@2.0.2
> - cordova-plugin-media-capture@3.0.3
> - cordova-plugin-network-information@2.0.2
> - cordova-plugin-screen-orientation@3.0.2
> - cordova-plugin-splashscreen@5.0.3
> - cordova-plugin-statusbar@2.4.3
> - cordova-plugin-vibration@3.1.1
> - cordova-plugin-whitelist@1.3.4
>
> I'll wait with a blog post until after the remaining 6 plugins plugins
> have also been voted on and been released, but of course these
> releases above can be used starting now.
>
> Jan

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



Re: [VOTE] (More) Plugins (patch) releases

2019-07-11 Thread Jan Piotrowski
The vote has now closed. The results are:

Positive Binding Votes: 3
* Brian Ellis
* Tim Brust
* Jan Piotrowski

Negative Binding Votes: 0

The vote has passed.

Thanks everyone!

Am Do., 11. Juli 2019 um 08:54 Uhr schrieb Bryan Ellis :
>
> +1
>
> * Confirmed the sigs & hashes with `coho verify-archive` for each plugin
> * Verified that sha matched tags with `coho verify-tags` for each plugin
> * Verified that each plugin tag had passing CI
>
>
> On Fri, Jun 28, 2019 at 9:51 PM Jan Piotrowski  wrote:
>
> > Please review and vote on the release of these plugins releases
> > by replying to this email (and keep discussion on the DISCUSS thread)
> >
> > The plugins have been published to dist/dev:
> > https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-file-6.0.2/
> >
> > https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-geolocation-4.0.2/
> > https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-media-5.0.3/
> >
> > The packages were published from their corresponding git tags:
> > cordova-plugin-geolocation: 4.0.2 (6319a2c1d6)
> > cordova-plugin-media: 5.0.3 (a3641b5411)
> > cordova-plugin-file: 6.0.2 (24dba9f4f9)
> >
> > Upon a successful vote I will upload the archives to dist/, upload
> > them to npm, and post the corresponding blog post.
> >
> > Voting guidelines:
> > https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
> > How to vote on a plugins release at
> >
> > https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#voting
> >
> > Voting will go on for a minimum of 48 hours.
> >
> > I vote +1:
> > * Ensured continuous build was green when repos were tagged
> >
> > -
> > 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: [VOTE] Plugins (minor) releases

2019-07-11 Thread Jan Piotrowski
The vote has now closed. The results are:

Positive Binding Votes: 3
* Jesse MacFadyen
* Tim Brust
* Jan Piotrowski

Negative Binding Votes: 0

The vote has passed.

Thanks everyone!

Am Mo., 8. Juli 2019 um 09:15 Uhr schrieb Jesse :
>
> +1
>
> - CI is green
> - reviewed changes
> - coho verify-archive
>
>
> On Sun, Jul 7, 2019 at 11:20 AM Tim Brust  wrote:
>
> > I vote +1 *for each:*
> > * CI is green
> > * coho verify-archive âś…
> > * coho check-license âś…
> > * npm audit âś…
> > * npm test âś…
> >
> >
> > On Fri, Jun 28, 2019 at 2:50 PM Jan Piotrowski 
> > wrote:
> >
> > > Please review and vote on the release of these plugins releases
> > > by replying to this email (and keep discussion on the DISCUSS thread)
> > >
> > > Two of these minor updates are comparably big, see their release notes:
> > >
> > >
> > https://github.com/apache/cordova-plugin-camera/blob/master/RELEASENOTES.md#410-jun-27-2019
> > >
> > >
> > https://github.com/apache/cordova-plugin-inappbrowser/blob/master/RELEASENOTES.md#310-jun-27-2019
> > >
> > > The plugins have been published to dist/dev:
> > >
> > https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-camera-4.1.0/
> > >
> > >
> > https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-inappbrowser-3.1.0/
> > >
> > >
> > https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-wkwebview-engine-1.2.0/
> > >
> > > The packages were published from their corresponding git tags:
> > > cordova-plugin-camera: 4.1.0 (ae3531acfa)
> > > cordova-plugin-inappbrowser: 3.1.0 (2ca1c923a2)
> > > cordova-plugin-wkwebview-engine: 1.2.0 (3015342f10)
> > >
> > > Upon a successful vote I will upload the archives to dist/, upload
> > > them to npm, and post the corresponding blog post.
> > >
> > > Voting guidelines:
> > >
> > https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
> > > How to vote on a plugins release at
> > >
> > >
> > https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#voting
> > >
> > > Voting will go on for a minimum of 48 hours.
> > >
> > > I vote +1:
> > > * Ensured continuous build was green when repos were tagged
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> > >
> >
> > --
> > Tim Brust
> > timbrust3...@gmail.com
> >
> > M: +49 160 9757 3632 <+4916097573632>
> >

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



[DISCUSS] Cordova Windows Release 7.1.0

2019-07-04 Thread 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.

(CI is currently red, so this will require some investigation.)

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



[ANNOUNCEMENT] Plugin Releases

2019-07-02 Thread Jan Piotrowski
We have just released an update to many of our plugins:

- cordova-plugin-battery-status@2.0.3
- cordova-plugin-device@2.0.3
- cordova-plugin-dialogs@2.0.2
- cordova-plugin-media-capture@3.0.3
- cordova-plugin-network-information@2.0.2
- cordova-plugin-screen-orientation@3.0.2
- cordova-plugin-splashscreen@5.0.3
- cordova-plugin-statusbar@2.4.3
- cordova-plugin-vibration@3.1.1
- cordova-plugin-whitelist@1.3.4

I'll wait with a blog post until after the remaining 6 plugins plugins
have also been voted on and been released, but of course these
releases above can be used starting now.

Jan

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



Re: [VOTE] Plugins (patch) releases

2019-07-02 Thread Jan Piotrowski
The vote has now closed. The results are:

Positive Binding Votes: 3
* Bryan Ellis
* Tim Brust
* Jan Piotrowski

Negative Binding Votes: 0

The vote has passed.

Thanks everyone!

Am Do., 27. Juni 2019 um 16:09 Uhr schrieb Tim Brust :
>
> I vote +1 *for each plugin*:
> * CI is green for release tag
> * coho verify-archive âś…
> * coho check-license âś…
> * npm audit âś…
> * Changes make sense
>
> On Wed, Jun 19, 2019 at 6:17 PM Jan Piotrowski  wrote:
>
> > Please review and vote on the release of these plugins releases
> > by replying to this email (and keep discussion on the DISCUSS thread)
> >
> > The plugins have been published to dist/dev:
> >
> > https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-dialogs-2.0.2/
> >
> > https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-network-information-2.0.2/
> >
> > https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-screen-orientation-3.0.2/
> >
> > https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-battery-status-2.0.3/
> >
> > https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-statusbar-2.4.3/
> >
> > https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-whitelist-1.3.4/
> >
> > https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-media-capture-3.0.3/
> >
> > The packages were published from their corresponding git tags:
> > cordova-plugin-dialogs: 2.0.2 (eadaaada6c)
> > cordova-plugin-network-information: 2.0.2 (561b13f917)
> > cordova-plugin-screen-orientation: 3.0.2 (95e664d6eb)
> > cordova-plugin-battery-status: 2.0.3 (93d27ca2d5)
> > cordova-plugin-statusbar: 2.4.3 (d456212b4c)
> > cordova-plugin-whitelist: 1.3.4 (5620d36aac)
> > cordova-plugin-media-capture: 3.0.3 (2d259ef291)
> >
> > Upon a successful vote I will upload the archives to dist/, upload
> > them to npm, and post the corresponding blog post.
> >
> > Voting guidelines:
> > https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
> > How to vote on a plugins release at
> >
> > https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#voting
> >
> > Voting will go on for a minimum of 48 hours.
> >
> > I vote +1:
> > * Ensured continuous build was green when repos were tagged
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>
> --
> Tim Brust
> timbrust3...@gmail.com
>
> M: +49 160 9757 3632 <+4916097573632>

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



Re: [VOTE] cordova-plugin-device Release 2.0.3

2019-07-02 Thread Jan Piotrowski
The vote has now closed. The results are:

Positive Binding Votes: 3
* Bryan Ellis
* Tim Brust
* Jan Piotrowski

Negative Binding Votes: 0

The vote has passed.

Thanks everyone!

Am Do., 27. Juni 2019 um 15:42 Uhr schrieb Tim Brust :
>
> I vote +1:
> * CI is green for release tag
> * coho verify-archive âś…
> * coho check-license âś…
> * npm audit âś…
> * Changes make sense
>
> On Sat, Jun 15, 2019 at 12:40 AM Jan Piotrowski 
> wrote:
>
> >  Please review and vote on the release of this plugins release
> > by replying to this email (and keep discussion on the DISCUSS thread)
> >
> > The plugins have been published to dist/dev:
> > https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-device-2.0.3/
> > <https://dist.apache.org/repos/dist/dev/cordova/splash20190509/>
> >
> > The packages were published from their corresponding git tags:
> > cordova-plugin-device: 2.0.3 (dc7b39be5b)
> >
> > Upon a successful vote I will upload the archives to dist/, upload
> > them to npm, and post the corresponding blog post.
> >
> > Voting guidelines:
> > https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
> > How to vote on a plugins release at
> >
> > https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#voting
> >
> > Voting will go on for a minimum of 48 hours.
> >
> > I vote +1:
> > * Ran coho audit-license-headers over the relevant repos
> > * Ran coho check-license to ensure all dependencies and
> > subdependencies have Apache-compatible licenses
> > * Ensured continuous build was green when repos were tagged
> >
>
>
> --
> Tim Brust
> timbrust3...@gmail.com
>
> M: +49 160 9757 3632 <+4916097573632>

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



Re: [VOTE] cordova-plugin-splashscreen Release 5.0.3

2019-07-02 Thread Jan Piotrowski
The vote has now closed. The results are:

Positive Binding Votes: 3
* Bryan Ellis
* Tim Brust
* Jan Piotrowski

Negative Binding Votes: 0

The vote has passed.

Thanks everyone!

Am Do., 27. Juni 2019 um 15:47 Uhr schrieb Tim Brust :
>
> I vote +1:
> * CI is green for release tag
> * coho verify-archive âś…
> * coho check-license âś…
> * npm audit âś…
> * Changes make sense
>
> On Thu, May 9, 2019 at 10:52 PM Jan Piotrowski  wrote:
>
> > Please review and vote on the release of this plugins release
> > by replying to this email (and keep discussion on the DISCUSS thread)
> >
> > The plugins have been published to dist/dev:
> > https://dist.apache.org/repos/dist/dev/cordova/splash20190509/
> >
> > The packages were published from their corresponding git tags:
> >  cordova-plugin-splashscreen: 5.0.3 (5339fcf377)
> >
> > Upon a successful vote I will upload the archives to dist/, upload
> > them to npm, and post the corresponding blog post.
> >
> > Voting guidelines:
> > https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
> > How to vote on a plugins release at
> >
> > https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#voting
> >
> > Voting will go on for a minimum of 48 hours.
> >
> > I vote +1:
> > * Ran coho audit-license-headers over the relevant repos
> > * Ran coho check-license to ensure all dependencies and
> > subdependencies have Apache-compatible licenses
> > * Ensured continuous build was green when repos were tagged
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>
> --
> Tim Brust
> timbrust3...@gmail.com
>
> M: +49 160 9757 3632 <+4916097573632>

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



Re: [VOTE] cordova-plugin-vibration Release 3.1.1

2019-07-02 Thread Jan Piotrowski
The vote has now closed. The results are:

Positive Binding Votes: 3
* Bryan Ellis
* Tim Brust
* Jan Piotrowski

Negative Binding Votes: 0

The vote has passed.

Thanks everyone!


Am So., 23. Juni 2019 um 10:28 Uhr schrieb Bryan Ellis :
>
> +1
>
> * Confirmed sigs & hashes with `coho verify-archive`
> * Verified sha match tags with `coho verify-tags`
> * Verified tag has passing CI
>
>
> On Thu, May 16, 2019 at 6:56 PM Jan Piotrowski  wrote:
>
> > Please review and vote on the release of this plugins release
> > by replying to this email (and keep discussion on the DISCUSS thread)
> >
> > The plugins have been published to dist/dev:
> >
> > https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-vibration%2381/
> >
> > The packages were published from their corresponding git tags:
> >  cordova-plugin-vibration: 3.1.1 (524ad47f2d)
> >
> > Upon a successful vote I will upload the archives to dist/, upload
> > them to npm, and post the corresponding blog post.
> >
> > Voting guidelines:
> > https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
> > How to vote on a plugins release at
> >
> > https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#voting
> >
> > Voting will go on for a minimum of 48 hours.
> >
> > I vote +1:
> > * Ran coho audit-license-headers over the relevant repos
> > * Ran coho check-license to ensure all dependencies and
> > subdependencies have Apache-compatible licenses
> > * Ensured continuous build was green when repos were tagged
> >
> > -
> > 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: [VOTE] Plugins (minor) releases

2019-06-28 Thread Jan Piotrowski
Small correction:

The package on dist/dev for inappbrowser was published from this
corresponding git tag:
cordova-plugin-inappbrowser: 3.1.0 (1cb4be15b8)

-J


Am Fr., 28. Juni 2019 um 14:50 Uhr schrieb Jan Piotrowski
:
>
> Please review and vote on the release of these plugins releases
> by replying to this email (and keep discussion on the DISCUSS thread)
>
> Two of these minor updates are comparably big, see their release notes:
> https://github.com/apache/cordova-plugin-camera/blob/master/RELEASENOTES.md#410-jun-27-2019
> https://github.com/apache/cordova-plugin-inappbrowser/blob/master/RELEASENOTES.md#310-jun-27-2019
>
> The plugins have been published to dist/dev:
> https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-camera-4.1.0/
> https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-inappbrowser-3.1.0/
> https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-wkwebview-engine-1.2.0/
>
> The packages were published from their corresponding git tags:
> cordova-plugin-camera: 4.1.0 (ae3531acfa)
> cordova-plugin-inappbrowser: 3.1.0 (2ca1c923a2)
> cordova-plugin-wkwebview-engine: 1.2.0 (3015342f10)
>
> Upon a successful vote I will upload the archives to dist/, upload
> them to npm, and post the corresponding blog post.
>
> Voting guidelines:
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
> How to vote on a plugins release at
> https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#voting
>
> Voting will go on for a minimum of 48 hours.
>
> I vote +1:
> * Ensured continuous build was green when repos were tagged

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



Re: [VOTE] Cordova-Electron 1.1.0 Release

2019-06-28 Thread Jan Piotrowski
+1

- CI is green
- Changes make sense
- I could successfully build an app with it

Am Fr., 28. Juni 2019 um 15:25 Uhr schrieb Tim Brust :
>
> I vote +1:
> * CI is green for release tag
> * coho verify-archive âś…
> * coho check-license âś…
> * npm audit âś…
> * npm test âś…
>
> On Fri, Jun 28, 2019 at 6:17 AM Bryan Ellis  wrote:
>
> > Please review and vote on this Electron Release v1.1.0
> > by replying to this email (and keep discussion on the DISCUSS thread)
> >
> > The archive has been published to dist/dev:
> > https://dist.apache.org/repos/dist/dev/cordova/electron-v1.1.0
> >
> > The package was published from its corresponding git tag:
> > cordova-electron: 1.1.0 (32dd1c40dc)
> >
> >
> > Note that you can test it out via:
> >
> > cordova platform add https://github.com/apache/cordova-electron#1.1.0
> >
> > Upon a successful vote I will upload the archive to dist/, publish it to
> > npm, and post the blog post.
> >
> > Voting guidelines:
> > https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
> >
> > Voting will go on for a minimum of 48 hours.
> >
> > I vote +1:
> > * Ran coho audit-license-headers over the relevant repos
> > * Ran coho check-license to ensure all dependencies and subdependencies
> > have Apache-compatible licenses
> > * Ensured continuous build was green when repo was tagged
> > * NPM Audit
> > * NPM Test
> >
>
>
> --
> Tim Brust
> timbrust3...@gmail.com
>
> M: +49 160 9757 3632 <+4916097573632>

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



[VOTE] (More) Plugins (patch) releases

2019-06-28 Thread Jan Piotrowski
Please review and vote on the release of these plugins releases
by replying to this email (and keep discussion on the DISCUSS thread)

The plugins have been published to dist/dev:
https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-file-6.0.2/
https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-geolocation-4.0.2/
https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-media-5.0.3/

The packages were published from their corresponding git tags:
cordova-plugin-geolocation: 4.0.2 (6319a2c1d6)
cordova-plugin-media: 5.0.3 (a3641b5411)
cordova-plugin-file: 6.0.2 (24dba9f4f9)

Upon a successful vote I will upload the archives to dist/, upload
them to npm, and post the corresponding blog post.

Voting guidelines:
https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
How to vote on a plugins release at
https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#voting

Voting will go on for a minimum of 48 hours.

I vote +1:
* Ensured continuous build was green when repos were tagged

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



[VOTE] Plugins (minor) releases

2019-06-28 Thread Jan Piotrowski
Please review and vote on the release of these plugins releases
by replying to this email (and keep discussion on the DISCUSS thread)

Two of these minor updates are comparably big, see their release notes:
https://github.com/apache/cordova-plugin-camera/blob/master/RELEASENOTES.md#410-jun-27-2019
https://github.com/apache/cordova-plugin-inappbrowser/blob/master/RELEASENOTES.md#310-jun-27-2019

The plugins have been published to dist/dev:
https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-camera-4.1.0/
https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-inappbrowser-3.1.0/
https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-wkwebview-engine-1.2.0/

The packages were published from their corresponding git tags:
cordova-plugin-camera: 4.1.0 (ae3531acfa)
cordova-plugin-inappbrowser: 3.1.0 (2ca1c923a2)
cordova-plugin-wkwebview-engine: 1.2.0 (3015342f10)

Upon a successful vote I will upload the archives to dist/, upload
them to npm, and post the corresponding blog post.

Voting guidelines:
https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
How to vote on a plugins release at
https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#voting

Voting will go on for a minimum of 48 hours.

I vote +1:
* Ensured continuous build was green when repos were tagged

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



Re: [VOTE] cordova-plugin-device Release 2.0.3

2019-06-19 Thread Jan Piotrowski
Note that the dist/dev link shows the correct link, but links to a wrong URL.
This is the correct one:
https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-device-2.0.3/

-J

Am Sa., 15. Juni 2019 um 00:40 Uhr schrieb Jan Piotrowski
:
>
> Please review and vote on the release of this plugins release
> by replying to this email (and keep discussion on the DISCUSS thread)
>
> The plugins have been published to dist/dev:
> https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-device-2.0.3/
>
> The packages were published from their corresponding git tags:
> cordova-plugin-device: 2.0.3 (dc7b39be5b)
>
> Upon a successful vote I will upload the archives to dist/, upload
> them to npm, and post the corresponding blog post.
>
> Voting guidelines:
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
> How to vote on a plugins release at
> https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#voting
>
> Voting will go on for a minimum of 48 hours.
>
> I vote +1:
> * Ran coho audit-license-headers over the relevant repos
> * Ran coho check-license to ensure all dependencies and
> subdependencies have Apache-compatible licenses
> * Ensured continuous build was green when repos were tagged

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



[VOTE] Plugins (patch) releases

2019-06-19 Thread Jan Piotrowski
Please review and vote on the release of these plugins releases
by replying to this email (and keep discussion on the DISCUSS thread)

The plugins have been published to dist/dev:
https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-dialogs-2.0.2/
https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-network-information-2.0.2/
https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-screen-orientation-3.0.2/
https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-battery-status-2.0.3/
https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-statusbar-2.4.3/
https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-whitelist-1.3.4/
https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-media-capture-3.0.3/

The packages were published from their corresponding git tags:
cordova-plugin-dialogs: 2.0.2 (eadaaada6c)
cordova-plugin-network-information: 2.0.2 (561b13f917)
cordova-plugin-screen-orientation: 3.0.2 (95e664d6eb)
cordova-plugin-battery-status: 2.0.3 (93d27ca2d5)
cordova-plugin-statusbar: 2.4.3 (d456212b4c)
cordova-plugin-whitelist: 1.3.4 (5620d36aac)
cordova-plugin-media-capture: 3.0.3 (2d259ef291)

Upon a successful vote I will upload the archives to dist/, upload
them to npm, and post the corresponding blog post.

Voting guidelines:
https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
How to vote on a plugins release at
https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#voting

Voting will go on for a minimum of 48 hours.

I vote +1:
* Ensured continuous build was green when repos were tagged

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



[VOTE] cordova-plugin-device Release 2.0.3

2019-06-14 Thread Jan Piotrowski
 Please review and vote on the release of this plugins release
by replying to this email (and keep discussion on the DISCUSS thread)

The plugins have been published to dist/dev:
https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-device-2.0.3/


The packages were published from their corresponding git tags:
cordova-plugin-device: 2.0.3 (dc7b39be5b)

Upon a successful vote I will upload the archives to dist/, upload
them to npm, and post the corresponding blog post.

Voting guidelines:
https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
How to vote on a plugins release at
https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#voting

Voting will go on for a minimum of 48 hours.

I vote +1:
* Ran coho audit-license-headers over the relevant repos
* Ran coho check-license to ensure all dependencies and
subdependencies have Apache-compatible licenses
* Ensured continuous build was green when repos were tagged


Re: [VOTE] cordova-common@3.2.0 tools release

2019-06-12 Thread Jan Piotrowski
+1

Changes since 3.1.0 look good.

(Waiting for CI to turn green on release commit though.)

Am Mi., 12. Juni 2019 um 10:59 Uhr schrieb Chris Brody <
chris.br...@gmail.com>:

> Please review and vote on this cordova-common@3.2.0 tools release by
> replying to this email (and keep discussion on the DISCUSS thread).
>
> cordova-common@3.2.0 tools release artifacts have been published to
> dist/dev:
> https://dist.apache.org/repos/dist/dev/cordova/cordova-common-3.2.0/
>
> The packages were published from their corresponding git tags:
>
> cordova-common: 3.2.0 (68014753da)
>
> Blog post is already proposed in:
> https://github.com/apache/cordova-docs/pull/1002
>
> Upon a successful vote I will upload the archives to dist/, publish
> them to npm, and post the corresponding blog post.
>
> Voting guidelines:
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
>
> Voting will go on for a minimum of 48 hours.
>
> I vote +1:
> * Ran coho audit-license-headers over the relevant repos
> * Ran coho check-license to ensure all dependencies and
> subdependencies have Apache-compatible licenses
> * Ensured continuous build was green when repos were tagged
> * npm audit shows no warning messages
> * I raised PRs including some DRAFT PRs for outdated packages that
> were indicated by: npm outdated
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>


Release Process: patch vs. minor bump on release

2019-05-26 Thread Jan Piotrowski
Hi all,

in the last few days I spent quite a lot of time trying to write an
abstracted release process documentation for all our different
components (as a base for some automation). During that, I discovered
that we actually have 2 very different release processes.

It boils down to these two variants:


a) after release, `master` gets a minor bump

> Prepares `master` for future development already: It gives version 
> (`package.json`, `VERSION` and similar) a minor bump and adds `-dev` (=> 
> `5.1.0-dev`) back
> ...
> coho prepare-platform-release-branch --version 5.0.0 -r android

https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md#create-release-branch
https://github.com/apache/cordova-coho/blob/c37742fafe3c7d0342a2b8deeb6aff41e100f7ad/src/platform-release.js#L34-L44

This results in `master` that can not be merged into release branch
any more even if there were no actual new features added that would
require the patch bump (as the release branch can only accept patch
increases, and merging would merge a minor increase).


b) after release, `master` gets a patch bump

https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#interactive-plugins-release
https://github.com/apache/cordova-coho/blob/c37742fafe3c7d0342a2b8deeb6aff41e100f7ad/src/plugin-release.js#L561
First command includes a patch bump:
https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#update-version-to-add-back--dev-suffix
https://github.com/apache/cordova-coho/blob/master/docs/tools-release-process.md#re-introduce--dev-suffix-to-versions-on-master-and-commit
https://github.com/apache/cordova-coho/blob/master/docs/app-hello-world-release-process.md#re-introduce--dev-suffix-to-versions-on-master
https://github.com/apache/cordova-coho/blob/master/docs/coho-release-process.md#re-introduce--dev-suffix-to-versions-on-master-and-commit

This results in a `master` that can just be merged into the release branch.


There are also differences when a release branch is created, how and
if the release branch is updated, when `-dev` is removed and re-added,
on which branch the actual tag is created, how a negative vote result
is handled on the repo, if the release branch also gets an automated
bump after release - but those are all outcomes of that very first
difference.


I suggest we unify our release processes on variant b), as it is
simpler and more flexible. If new features are added, the minor bump
to the version string should be a conscious change, not something that
is assumed at the time of previous release already.

Any objections?
Who supports this?

Best,
Jan

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



Re: Plugins and Node.js versions

2019-05-17 Thread Jan Piotrowski
Additional thought:
This means that it doesn't make sense to test plugins in multiple
Node.js versions as well, the best and fastest is always ok for
plugins, correct?

-J

Am Fr., 17. Mai 2019 um 07:49 Uhr schrieb Jesse :
>
> Sounds good to me.
> Faster CI is better CI
>
>
> On Thu, May 16, 2019 at 2:16 PM Jan Piotrowski  wrote:
>
> > None of the plugins have a `hooks` directory or anything else that
> > looks similar.
> >
> > Is anyone aware of any script in the plugin repositories that is
> > executed on the developer side?
> >
> > Otherwise I think we should be good to define adding and dropping
> > Node.js versions as non-breaking for plugins.
> >
> > Best,
> > Jan
> >
> > Am Sa., 11. Mai 2019 um 10:49 Uhr schrieb :
> > >
> > > Sounds like a good idea under the premise that our plugins really do not
> > > contain any scripts that
> > > are executed on the developer machine.
> > >
> > > But aren't there any core plugins that define hooks?
> > >
> > > Am Sa., 11. Mai 2019 um 10:03 Uhr schrieb Jan Piotrowski <
> > > piotrow...@gmail.com>:
> > >
> > > > Currently our plugin CI uses the same version of Node.js as Tooling
> > > > and Platforms, until recently 4.2 and now 6.
> > > >
> > > > But if I am not mistaken, our plugins do not contain any scripts that
> > > > are executed on the developer machine, only JavaScript files that are
> > > > run inside the app or native code. So it doesn't really matter what
> > > > node version is used to run our plugin CI tests as it doesn't run any
> > > > actual scripts (vs. with platforms, we have scripts that are actually
> > > > run by the developer).
> > > >
> > > > Could we maybe just go to node 10 or 12 with our plugins right now?
> > > >
> > > > This would give as quite some time until we have to update our CI
> > > > configuration again, and possibly also quicker installs and builds.
> > > >
> > > > 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
> >
> >

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



Re: Plugins and Node.js versions

2019-05-16 Thread Jan Piotrowski
None of the plugins have a `hooks` directory or anything else that
looks similar.

Is anyone aware of any script in the plugin repositories that is
executed on the developer side?

Otherwise I think we should be good to define adding and dropping
Node.js versions as non-breaking for plugins.

Best,
Jan

Am Sa., 11. Mai 2019 um 10:49 Uhr schrieb :
>
> Sounds like a good idea under the premise that our plugins really do not
> contain any scripts that
> are executed on the developer machine.
>
> But aren't there any core plugins that define hooks?
>
> Am Sa., 11. Mai 2019 um 10:03 Uhr schrieb Jan Piotrowski <
> piotrow...@gmail.com>:
>
> > Currently our plugin CI uses the same version of Node.js as Tooling
> > and Platforms, until recently 4.2 and now 6.
> >
> > But if I am not mistaken, our plugins do not contain any scripts that
> > are executed on the developer machine, only JavaScript files that are
> > run inside the app or native code. So it doesn't really matter what
> > node version is used to run our plugin CI tests as it doesn't run any
> > actual scripts (vs. with platforms, we have scripts that are actually
> > run by the developer).
> >
> > Could we maybe just go to node 10 or 12 with our plugins right now?
> >
> > This would give as quite some time until we have to update our CI
> > configuration again, and possibly also quicker installs and builds.
> >
> > 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] coho: Change the default folder it works on

2019-05-16 Thread Jan Piotrowski
While rewriting the plugin release documentation, I stumbled over the
way coho chooses the directory where it does its changes. As this is
probably just because of historical reasons, I suggest we change the
way it works:

https://github.com/apache/cordova-coho/issues/238

Is there any reason to keep the old behavior?
Any use case that is used frequently but that I missed that depends on
it working this way?

If there are no replies that suggest otherwise, I will go forward with
the issue some time next week.

Best,
Jan

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



[VOTE] cordova-plugin-vibration Release 3.1.1

2019-05-16 Thread Jan Piotrowski
Please review and vote on the release of this plugins release
by replying to this email (and keep discussion on the DISCUSS thread)

The plugins have been published to dist/dev:
https://dist.apache.org/repos/dist/dev/cordova/cordova-plugin-vibration%2381/

The packages were published from their corresponding git tags:
 cordova-plugin-vibration: 3.1.1 (524ad47f2d)

Upon a successful vote I will upload the archives to dist/, upload
them to npm, and post the corresponding blog post.

Voting guidelines:
https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
How to vote on a plugins release at
https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#voting

Voting will go on for a minimum of 48 hours.

I vote +1:
* Ran coho audit-license-headers over the relevant repos
* Ran coho check-license to ensure all dependencies and
subdependencies have Apache-compatible licenses
* Ensured continuous build was green when repos were tagged

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



Re: [DISCUSS] Remove all documentation translations

2019-05-16 Thread Jan Piotrowski
I would say "No" to 1) and 3) - we can get rid of the code and
deactivate that account.

2) and 4) definitely need their own mailing list thread with their own
reasoning.

-J

Am Do., 16. Mai 2019 um 07:19 Uhr schrieb Dmitry Blotsky
:
>
> Ok, if that’s reality, then it’s reality. Then, if we’re on the topic of 
> dropping translations, let’s revisit the whole commitment.
>
> I’d be interested to know:
> 1. Do we want to keep the Crowdin account?
> 2. How many versions of docs are we keeping? Maybe we can prune some.
> 3. Do we want to keep support for translations for the future? Removing it 
> would allow us to delete a lot of code, but also would be harder to bring 
> back.
> 4. Do we even have a supported versions list? An LTS? If not, maybe let’s 
> start.
>
> What do you all think?
>
> Dmitry
>
> > On May 15, 2019, at 09:54, Darryl Pogue  wrote:
> >
> >> On Wed, May 15, 2019 at 9:24 AM Dmitry Blotsky  
> >> wrote:
> >>
> >> Would anyone that works on Cordova full-time be up to prioritise this?
> >
> > As far as I know, there has been nobody working full-time on Cordova
> > for the past year. There are a few companies putting some dev time
> > against the project, but it's almost entirely maintained by people in
> > their limited spare time nowadays.
> >
> > -
> > 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



Plugins and Node.js versions

2019-05-11 Thread Jan Piotrowski
Currently our plugin CI uses the same version of Node.js as Tooling
and Platforms, until recently 4.2 and now 6.

But if I am not mistaken, our plugins do not contain any scripts that
are executed on the developer machine, only JavaScript files that are
run inside the app or native code. So it doesn't really matter what
node version is used to run our plugin CI tests as it doesn't run any
actual scripts (vs. with platforms, we have scripts that are actually
run by the developer).

Could we maybe just go to node 10 or 12 with our plugins right now?

This would give as quite some time until we have to update our CI
configuration again, and possibly also quicker installs and builds.

Best,
Jan

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



Re: Plugin CI: Updates to OS/versions

2019-05-10 Thread Jan Piotrowski
The work on https://github.com/apache/cordova-paramedic continued and
we settled on a set of OS/version combinations to test.
I rewrote the script so that is can be mostly just copied over to the
plugins, making it unnecessary to maintain different versions for
paramedic and the plugins.

The first repository where this was rolled out as release preparation was:
https://github.com/apache/cordova-plugin-splashscreen
That release is currently in vote.

Today I rolled out the new paramedic travis.yml to the remaining plugins.


These plugins all pass:

https://github.com/apache/cordova-plugin-vibration/pull/80
https://github.com/apache/cordova-plugin-battery-status/pull/75
https://github.com/apache/cordova-plugin-device/pull/97
https://github.com/apache/cordova-plugin-dialogs/pull/127
https://github.com/apache/cordova-plugin-network-information/pull/89
https://github.com/apache/cordova-plugin-screen-orientation/pull/47
https://github.com/apache/cordova-plugin-statusbar/pull/139
https://github.com/apache/cordova-plugin-media-capture/pull/134

Please review the PRs so these can be merged.


Unfortunately the remaining plugins do not pass CI right now:

https://github.com/apache/cordova-plugin-inappbrowser/pull/478
iOS 12 and 12.2 fail when running tests on SauceLabs: "Remote debugger
error with code '-32601': 'Page' domain was not found"
(Probably something to do with the webview of InAppBrowser not being accessible)
Problem is tracked at https://github.com/apache/cordova-paramedic/issues/149

https://github.com/apache/cordova-plugin-file/pull/314
Chrome and iOS 11.3 and 12 fail, with some individual test failures.
(All 3 platforms were not tested before)

https://github.com/apache/cordova-plugin-geolocation/pull/154
Fails in Firefox, Safari and Edge - and local iOS 10 and browser with
individual failures.
(All platform were not tested before)

https://github.com/apache/cordova-plugin-media/pull/227
Local iOS 10 and browser fail (both was not tested before)

https://github.com/apache/cordova-plugin-camera/pull/455
Local iOS 10 fails - this might be a bug in paramedic that is tracked
in https://github.com/apache/cordova-paramedic/issues/142
All iOS and Android Appium tests fail. First investigation at
https://github.com/apache/cordova-paramedic/issues/145
This is one of only 2 plugins that have Appium tests (the other is
deprecated contacts plugin), so clearly something is wrong with Appium
tests.

https://github.com/apache/cordova-plugin-wkwebview-engine/pull/93
Local iOS 10 and normal iOS 12.2 tests are failing for different
reasons (iOS 12.2 is similar to InAppBrowser plugin mentioned above)

For all these, we will have to investigate and fix - or remove the CI
builds where appropriate (e.g. testing on browsers where the Browser
platform is not even supported).


I am still quite happy with the success rate, 9 success vs. 6 fail is
better than I expected.

Best,
Jan


Am Mi., 24. Apr. 2019 um 17:27 Uhr schrieb Jan Piotrowski
:
>
> We (@erisu and me) now got this working for paramedic on all the
> mentioned platforms, and have a green build again:
> https://github.com/apache/cordova-paramedic
>
> First adaptations to plugin repos can be seen here:
> https://github.com/apache/cordova-plugin-inappbrowser/pull/465 (@erisu)
> https://github.com/apache/cordova-plugin-vibration/pull/76 (@timbru31)
>
> If you have any feedback, _now_ is the time to give it before be
> continue with this.
>
> (I got a private inquiry why we did not add Android 9.0 to the list of
> platforms. Unfortunately SauceLabs does not support Android 9 yet)
>
> -J
>
> Am Mo., 15. Apr. 2019 um 14:08 Uhr schrieb Jan Piotrowski
> :
> >
> > Hi,
> >
> > in the last few days I have been working on fixing and updating the CI
> > configuration of our plugins, so they actually work with Cordova CLI 9
> > and are tested on all relevant OS versions via SauceLabs.
> >
> > You might know that our plugin tests are run via cordova-paramedic,
> > which means that the CI configuration of our plugins are actually just
> > copies of the CI configuration of paramedic itself - so that is where
> > we started - updating Paramedic's CI configuration.
> >
> > This is where we ended up:
> > (OS/version that were already tested are marked with *)
> >
> > iOS 10.0 *
> > iOS 11.3
> > iOS 12.0
> > iOS 12.2
> >
> > Android 4.4
> > Android 5.1
> > Android 6.0,
> > Android 7.0 *
> > Android 7.1
> > Android 8.0
> > Android 8.1
> >
> > Chrome *
> > Safari
> > Firefox
> > Edge
> >
> > Any relevant OS/versions missing?
> > Any OS/version not useful to test on?
> >
> > Along the way I rewrote the .travis.yml to hopefully be a lot more
> > maintainable by movi

Re: [DISCUSS] non-global Cordova installs

2019-05-10 Thread Jan Piotrowski
While that is correct, nvm-windows indeed had problems with npx not
working after it was first added to node - so Julio's was indeed true
in the past.
Luckily it was fixed, so even we lowly Windows users now can use npx.

Am Fr., 10. Mai 2019 um 09:48 Uhr schrieb Oliver Salzburg
:
>
> npx ships with Node.
>
> On Fri, May 10, 2019, 00:33 Jesse  wrote:
>
> > Hello Dmitry,
> >
> > In my mind, cordova-cli is intended to be installed globally, in situations
> > where that is not is possible we could *maybe* recommend that users use
> > npx, but I don't think it's a great experience.  btw, npx needs to be
> > globally installed ... so ok!?
> > This is really just a symptom of a bad node setup, and would never happen
> > if using nvm or similar node switcher.
> >
> > The issue raised in that thread appears to be simply related to where
> > config stores its data, specifically opt in/out of telemetry.
> >
> >
> >
> >
> > On Thu, May 9, 2019 at 2:45 PM Dmitry Blotsky 
> > wrote:
> >
> > > Hi all,
> > >
> > > It’s been a while. :) I hope you’re all doing well.
> > >
> > > I’m writing to start some mailing list discussion about this GitHub
> > issue:
> > > https://github.com/apache/cordova-docs/issues/838.
> > >
> > > Please say if we should continue talking there, and we can do that
> > instead.
> > >
> > > If not, let’s continue here.
> > >
> > > It sounds like we’ve got a request to run Cordova without a global sudo
> > > install. What are the ways you all can think of to achieve this?
> > >
> > > Dmitry
> >

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



Re: [DISCUSS] non-global Cordova installs

2019-05-10 Thread Jan Piotrowski
Afaik nvm-windows also supports npx for quite some time [1], with
1.1.7 it works for every new-ish node I installed.

[1] 
https://github.com/coreybutler/nvm-windows/commit/ce756027a816042ed41c3ee60b18d0ebc2599c2b

Am Fr., 10. Mai 2019 um 02:09 Uhr schrieb julio cesar sanchez
:
>
> npx is included in npm 5.2 and greater (the one that comes with node 8 I
> think)
> Looks line nvm-windows doesn’t include it for some reason, but nvm for
> macOS does.
>
> El El vie, 10 may 2019 a las 0:33, Jesse  escribiĂł:
>
> > Hello Dmitry,
> >
> > In my mind, cordova-cli is intended to be installed globally, in situations
> > where that is not is possible we could *maybe* recommend that users use
> > npx, but I don't think it's a great experience.  btw, npx needs to be
> > globally installed ... so ok!?
> > This is really just a symptom of a bad node setup, and would never happen
> > if using nvm or similar node switcher.
> >
> > The issue raised in that thread appears to be simply related to where
> > config stores its data, specifically opt in/out of telemetry.
> >
> >
> >
> >
> > On Thu, May 9, 2019 at 2:45 PM Dmitry Blotsky 
> > wrote:
> >
> > > Hi all,
> > >
> > > It’s been a while. :) I hope you’re all doing well.
> > >
> > > I’m writing to start some mailing list discussion about this GitHub
> > issue:
> > > https://github.com/apache/cordova-docs/issues/838.
> > >
> > > Please say if we should continue talking there, and we can do that
> > instead.
> > >
> > > If not, let’s continue here.
> > >
> > > It sounds like we’ve got a request to run Cordova without a global sudo
> > > install. What are the ways you all can think of to achieve this?
> > >
> > > Dmitry
> >

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



Re: [DISCUSS] Plugin Releases

2019-05-09 Thread Jan Piotrowski
After we got the Cordova Paramedic Travis CI configuration in a state
that enabled simple copy/paste to plugin repositories, I applied that
to the Splashscreen plugin as announced. With a green build, I started
the release process just for this plugin.

Along the way, I had to update the plugin release process documentation a lot:
https://github.com/apache/cordova-coho/pull/233
https://github.com/apache/cordova-coho/pull/233/files?short_path=204db0c#diff-204db0c8ef1a508dc7694641e31ff36d
https://github.com/apache/cordova-coho/blob/4cea733a9f873ff1b4fd39353925463fcb5a5eb6/docs/plugins-release-process.md
(current state)
(Interesting bits: The old docs forgot to update version in
tests/package.json, which probably means those are outdated in all or
most plugins)

But everything seems to have gone well, you should already have gotten
the vote message:

https://github.com/apache/cordova-plugin-splashscreen/commits/master
https://github.com/apache/cordova-plugin-splashscreen/releases/tag/5.0.3
https://dist.apache.org/repos/dist/dev/cordova/splash20190509/
https://github.com/apache/cordova-plugin-splashscreen/tree/5.0.x
https://github.com/apache/cordova-plugin-splashscreen/commits/5.0.x

I am not fully happy with the "merge master into release branch", the
single merge commit just doesn't contain any relevant information -
but that is how it was documented.

Another thing that might need some iteration is the "Release
Identifier"  concept that I introduced as an alternative to the old
"JIRA ID as release identifier" thing. For this release I used
`splash20190509` which you can see on dist-dev and in several commit
messages. It works, but is a bit "hidden" - the JIRA ID had a more
obvious structure.
We could use GitHub issue IDs, which would be equal to how PRs use it
in the squash commit message, but this only works for single-repo
releases because issue IDs are only unique per repository, not
globally. (Using IDs from another repo would also be confusing.) And
especially with plugins I hope we can soon do releases of many plugins
at the same time again, so this is not a solution.
Ideas?

Best,
Jan

Am Mi., 8. Mai 2019 um 20:11 Uhr schrieb Jan Piotrowski :
>
> This is now being tracked in https://github.com/apache/cordova/issues/104
>
> Am Mo., 6. Mai 2019 um 12:19 Uhr schrieb Jan Piotrowski 
> :
> >
> > Does anyone have any reasons to delay Cordova Plugins releases?
> > If not, I will start the releases tomorrow.
> >
> >
> > Cordova Paramedic is soon [1] in a state where we can start rolling
> > out its CI configuration to our plugin repositories. This will enable
> > us to evaluate the state of a plugin repository again, which will also
> > enable us to do plugin releases.
> >
> > I already trialed that for
> > https://github.com/apache/cordova-plugin-splashscreen, you can follow
> > the process at 
> > https://github.com/apache/cordova-plugin-splashscreen/issues/199.
> >
> >
> > The plan for the plugins would be as follows:
> >
> > 1. Create patch or minor releases of the current state of master
> > - Update CI config
> > - If master includes breaking changes, skip that plugin for now
> > - If master is currently broken, fix it to get to a releasable state
> > 2. Create major releases for the plugins skipped in 1 with current
> > state of master
> > - If master is currently broken, fix it to get to a releasable state
> >
> > While 1 and 2 are happening, the plugin release documentation [2] gets
> > updated to a usable state. I already started that process in [3]
> >
> > 3. After all plugins have their current master released, we can start
> > rebasing and merging existing Pull Requests. This will probably lead
> > to additional minor or major releases down the road.
> >
> > This is a pretty major undertaking, so all help is appreciated.
> > I will post current problems and PRs in the #dev channel in Slack.
> > A more general help of course is to look at issues and pull requests
> > in the plugin repositories (Pick one plugin you like, go through all
> > of them to see if they make sense and try to get them to a point where
> > they do - I did the same for
> > https://github.com/apache/cordova-plugin-splashscreen for example).
> >
> > Best,
> > Jan
> >
> >
> > [1] https://github.com/apache/cordova-paramedic/pull/131
> > [2] 
> > https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md
> > [3] https://github.com/apache/cordova-coho/pull/233

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



[VOTE] cordova-plugin-splashscreen Release 5.0.3

2019-05-09 Thread Jan Piotrowski
Please review and vote on the release of this plugins release
by replying to this email (and keep discussion on the DISCUSS thread)

The plugins have been published to dist/dev:
https://dist.apache.org/repos/dist/dev/cordova/splash20190509/

The packages were published from their corresponding git tags:
 cordova-plugin-splashscreen: 5.0.3 (5339fcf377)

Upon a successful vote I will upload the archives to dist/, upload
them to npm, and post the corresponding blog post.

Voting guidelines:
https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
How to vote on a plugins release at
https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md#voting

Voting will go on for a minimum of 48 hours.

I vote +1:
* Ran coho audit-license-headers over the relevant repos
* Ran coho check-license to ensure all dependencies and
subdependencies have Apache-compatible licenses
* Ensured continuous build was green when repos were tagged

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



Re: [DISCUSS] Plugin Releases

2019-05-08 Thread Jan Piotrowski
This is now being tracked in https://github.com/apache/cordova/issues/104

Am Mo., 6. Mai 2019 um 12:19 Uhr schrieb Jan Piotrowski :
>
> Does anyone have any reasons to delay Cordova Plugins releases?
> If not, I will start the releases tomorrow.
>
>
> Cordova Paramedic is soon [1] in a state where we can start rolling
> out its CI configuration to our plugin repositories. This will enable
> us to evaluate the state of a plugin repository again, which will also
> enable us to do plugin releases.
>
> I already trialed that for
> https://github.com/apache/cordova-plugin-splashscreen, you can follow
> the process at 
> https://github.com/apache/cordova-plugin-splashscreen/issues/199.
>
>
> The plan for the plugins would be as follows:
>
> 1. Create patch or minor releases of the current state of master
> - Update CI config
> - If master includes breaking changes, skip that plugin for now
> - If master is currently broken, fix it to get to a releasable state
> 2. Create major releases for the plugins skipped in 1 with current
> state of master
> - If master is currently broken, fix it to get to a releasable state
>
> While 1 and 2 are happening, the plugin release documentation [2] gets
> updated to a usable state. I already started that process in [3]
>
> 3. After all plugins have their current master released, we can start
> rebasing and merging existing Pull Requests. This will probably lead
> to additional minor or major releases down the road.
>
> This is a pretty major undertaking, so all help is appreciated.
> I will post current problems and PRs in the #dev channel in Slack.
> A more general help of course is to look at issues and pull requests
> in the plugin repositories (Pick one plugin you like, go through all
> of them to see if they make sense and try to get them to a point where
> they do - I did the same for
> https://github.com/apache/cordova-plugin-splashscreen for example).
>
> Best,
> Jan
>
>
> [1] https://github.com/apache/cordova-paramedic/pull/131
> [2] 
> https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md
> [3] https://github.com/apache/cordova-coho/pull/233

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



[DISCUSS] Plugin Releases

2019-05-06 Thread Jan Piotrowski
Does anyone have any reasons to delay Cordova Plugins releases?
If not, I will start the releases tomorrow.


Cordova Paramedic is soon [1] in a state where we can start rolling
out its CI configuration to our plugin repositories. This will enable
us to evaluate the state of a plugin repository again, which will also
enable us to do plugin releases.

I already trialed that for
https://github.com/apache/cordova-plugin-splashscreen, you can follow
the process at https://github.com/apache/cordova-plugin-splashscreen/issues/199.


The plan for the plugins would be as follows:

1. Create patch or minor releases of the current state of master
- Update CI config
- If master includes breaking changes, skip that plugin for now
- If master is currently broken, fix it to get to a releasable state
2. Create major releases for the plugins skipped in 1 with current
state of master
- If master is currently broken, fix it to get to a releasable state

While 1 and 2 are happening, the plugin release documentation [2] gets
updated to a usable state. I already started that process in [3]

3. After all plugins have their current master released, we can start
rebasing and merging existing Pull Requests. This will probably lead
to additional minor or major releases down the road.

This is a pretty major undertaking, so all help is appreciated.
I will post current problems and PRs in the #dev channel in Slack.
A more general help of course is to look at issues and pull requests
in the plugin repositories (Pick one plugin you like, go through all
of them to see if they make sense and try to get them to a point where
they do - I did the same for
https://github.com/apache/cordova-plugin-splashscreen for example).

Best,
Jan


[1] https://github.com/apache/cordova-paramedic/pull/131
[2] 
https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md
[3] https://github.com/apache/cordova-coho/pull/233

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



What is in a platform?

2019-05-02 Thread Jan Piotrowski
Imagine I want to create a new Cordova platform.

What documentation should I read?
Which repositories can help me?
I see https://github.com/apache/cordova-test-platform exists, but is this
complete and current?
What functionality should I implement first?

Is there a way to "fake" a platform until I fully implemented it? Something
like having a "static" project that doesn't support all the configuration
options that Cordova platforms usually have, to simplify the initial
implementation load that needs to be done.

Any other pointers?

Best,
Jan


Re: Native (C#, C++) UI plugins for Cordova Windows?

2019-05-02 Thread Jan Piotrowski
Which is all nice and interesting but absolutely unrelated to this thread's
topic and my initial question.
Please stop moving threads offtopic and create your own mailing list thread
if you want to talk about something.
Thanks.

Am Do., 2. Mai 2019 um 00:31 Uhr schrieb Chris Brody :

> > Is it possible to create User Interface with native (C#, C++) plugins
> > for Cordova Windows?
>
> What about https://github.com/nodekit-io/nodekit-windows ?
>
> > Windows Store apps and Electron apps are inherently separate things.
>
>
> https://www.microsoft.com/developerblog/2016/05/08/compiling-electron-apps-for-the-windows-store/
>
> > For Windows, do we even need Cordova anymore? PWAs can be submitted to
> > the Windows Store, which sounds to me like fulfillment of the original
> > Phonegap objective.
>
> :tada:
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>


Re: Native (C#, C++) UI plugins for Cordova Windows?

2019-05-01 Thread Jan Piotrowski
Thanks for the confirmation what I suspected.

-J

Am Mi., 1. Mai 2019 um 22:39 Uhr schrieb Jesse :
>
> Unfortunately, No.  C#/C++ Portable Class Library ( PCL ) code cannot
> render on top of the web component.
> The libraries that you can use are limited in PCLs and for projects
> targeting Windows Store it is not possible to render UI.
> If the entire cordova-windows platform were re-architected to be a C# or
> C++ based application, with a native webview container in which to render,
> then everything is possible.  This is a long risky road though ...
> everything from the cordova.js and the bridge would have to change, and
> every plugin would need to be rewritten.
>
> Cheers,
>   Jesse
>
> @purplecabbage
> risingj.com
>
>
> On Wed, May 1, 2019 at 1:03 PM Jan Piotrowski  wrote:
>
> > For Cordova iOS and Cordova Android it is possible to create plugins
> > that create native UI on top of your app - you just include the
> > libraries in your plugin and execute their API. Example for Android
> > InAppBrowser:
> > https://github.com/apache/cordova-plugin-inappbrowser/blob/a162bd90764e7b3c6a5f8b2f394e7ff71ba166d5/src/android/InAppBrowser.java#L920-L922
> >
> > For Cordova Windows, the native code _is_ HTML and Javascript, hence
> > the InAppBrowser plugin also adds a standard HTML tag for a Webview
> > (or even plain Iframe) to get the same effect:
> >
> > https://github.com/apache/cordova-plugin-inappbrowser/blob/master/src/windows/InAppBrowserProxy.js#L177-L182
> >
> > But you can also create plugins for Cordova Windows that use C# or C++
> > native code via a Windows Runtime Component. A public example is the
> > globalization plugin that uses a `.winmd` file to offer APIs to the
> > Javascript code
> >
> > https://github.com/apache/cordova-plugin-globalization/tree/master/src/windows/
> > (source for that lives in
> >
> > https://github.com/apache/cordova-plugin-globalization/blob/master/src/windows/GlobalizationProxy/GlobalizationProxy/Globalization/GlobalizationImpl.cs
> > ).
> > This works great and is pretty awesome.
> >
> > Unfortunately all the plugins that I could find use this C#/C++ native
> > plugin mechanism only to receive some method call, do something with
> > the parameters and return some data. None of those open any windows or
> > create any other GUI (that might for example be offered by an external
> > C# SDK).
> >
> > Is it possible to create User Interface with native (C#, C++) plugins
> > 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



Native (C#, C++) UI plugins for Cordova Windows?

2019-05-01 Thread Jan Piotrowski
For Cordova iOS and Cordova Android it is possible to create plugins
that create native UI on top of your app - you just include the
libraries in your plugin and execute their API. Example for Android
InAppBrowser: 
https://github.com/apache/cordova-plugin-inappbrowser/blob/a162bd90764e7b3c6a5f8b2f394e7ff71ba166d5/src/android/InAppBrowser.java#L920-L922

For Cordova Windows, the native code _is_ HTML and Javascript, hence
the InAppBrowser plugin also adds a standard HTML tag for a Webview
(or even plain Iframe) to get the same effect:
https://github.com/apache/cordova-plugin-inappbrowser/blob/master/src/windows/InAppBrowserProxy.js#L177-L182

But you can also create plugins for Cordova Windows that use C# or C++
native code via a Windows Runtime Component. A public example is the
globalization plugin that uses a `.winmd` file to offer APIs to the
Javascript code
https://github.com/apache/cordova-plugin-globalization/tree/master/src/windows/
(source for that lives in
https://github.com/apache/cordova-plugin-globalization/blob/master/src/windows/GlobalizationProxy/GlobalizationProxy/Globalization/GlobalizationImpl.cs).
This works great and is pretty awesome.

Unfortunately all the plugins that I could find use this C#/C++ native
plugin mechanism only to receive some method call, do something with
the parameters and return some data. None of those open any windows or
create any other GUI (that might for example be offered by an external
C# SDK).

Is it possible to create User Interface with native (C#, C++) plugins
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: Plugin CI: Updates to OS/versions

2019-04-24 Thread Jan Piotrowski
We (@erisu and me) now got this working for paramedic on all the
mentioned platforms, and have a green build again:
https://github.com/apache/cordova-paramedic

First adaptations to plugin repos can be seen here:
https://github.com/apache/cordova-plugin-inappbrowser/pull/465 (@erisu)
https://github.com/apache/cordova-plugin-vibration/pull/76 (@timbru31)

If you have any feedback, _now_ is the time to give it before be
continue with this.

(I got a private inquiry why we did not add Android 9.0 to the list of
platforms. Unfortunately SauceLabs does not support Android 9 yet)

-J

Am Mo., 15. Apr. 2019 um 14:08 Uhr schrieb Jan Piotrowski
:
>
> Hi,
>
> in the last few days I have been working on fixing and updating the CI
> configuration of our plugins, so they actually work with Cordova CLI 9
> and are tested on all relevant OS versions via SauceLabs.
>
> You might know that our plugin tests are run via cordova-paramedic,
> which means that the CI configuration of our plugins are actually just
> copies of the CI configuration of paramedic itself - so that is where
> we started - updating Paramedic's CI configuration.
>
> This is where we ended up:
> (OS/version that were already tested are marked with *)
>
> iOS 10.0 *
> iOS 11.3
> iOS 12.0
> iOS 12.2
>
> Android 4.4
> Android 5.1
> Android 6.0,
> Android 7.0 *
> Android 7.1
> Android 8.0
> Android 8.1
>
> Chrome *
> Safari
> Firefox
> Edge
>
> Any relevant OS/versions missing?
> Any OS/version not useful to test on?
>
> Along the way I rewrote the .travis.yml to hopefully be a lot more
> maintainable by moving all version stuff (Android SDK and tools...) to
> the top. Tim Brust helped me to fix a bug in Paramedic that popped up
> with newer iOS versions.
>
> Best,
> Jan

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



Re: [VOTE] cordova-ios 5.0.1 release

2019-04-22 Thread Jan Piotrowski
+1

* CI is green
* Diff makes sense
* release branch looks right

Am Fr., 19. Apr. 2019 um 02:53 Uhr schrieb Bryan Ellis :
>
> +1
>
> * Verified archive signatures & hashes with `coho verify-archive`
> * Verified tags SHA with `coho verify-tags`
> * Re-created npm package to validate matching release candidate content
> * Ran NPM Test
> * Tested Platform `add`, `run` and `build`
>
>
>
>
> From: Pogue Darryl 
> Reply: dev@cordova.apache.org 
> Date: April 19, 2019 at 6:41:23
> To: dev@cordova.apache.org 
> Subject:  [VOTE] cordova-ios 5.0.1 release
>
> Please review and vote on this 5.0.1 iOS Release by replying to this
> email (and keep discussion on the DISCUSS thread)
>
> The archive has been published to dist/dev:
> https://dist.apache.org/repos/dist/dev/cordova/ios501
>
> The package was published from its corresponding git tag:
> cordova-ios: 5.0.1 (3b9e044d56)
>
> Note that you can test it out via:
> cordova platform add https://github.com/apache/cordova-ios#5.0.1
>
> Upon a successful vote I will upload the archive to dist/, publish it
> to npm, and post the blog post.
>
> Voting guidelines:
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
>
> Voting will go on for a minimum of 48 hours.
>
> I vote +1:
> * Ran coho audit-license-headers over the relevant repos
> * Ran coho check-license to ensure all dependencies and
> subdependencies have Apache-compatible licenses
> * Ensured continuous build was green when repo was tagged
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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



Plugin CI: Updates to OS/versions

2019-04-15 Thread Jan Piotrowski
Hi,

in the last few days I have been working on fixing and updating the CI
configuration of our plugins, so they actually work with Cordova CLI 9
and are tested on all relevant OS versions via SauceLabs.

You might know that our plugin tests are run via cordova-paramedic,
which means that the CI configuration of our plugins are actually just
copies of the CI configuration of paramedic itself - so that is where
we started - updating Paramedic's CI configuration.

This is where we ended up:
(OS/version that were already tested are marked with *)

iOS 10.0 *
iOS 11.3
iOS 12.0
iOS 12.2

Android 4.4
Android 5.1
Android 6.0,
Android 7.0 *
Android 7.1
Android 8.0
Android 8.1

Chrome *
Safari
Firefox
Edge

Any relevant OS/versions missing?
Any OS/version not useful to test on?

Along the way I rewrote the .travis.yml to hopefully be a lot more
maintainable by moving all version stuff (Android SDK and tools...) to
the top. Tim Brust helped me to fix a bug in Paramedic that popped up
with newer iOS versions.

Best,
Jan

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



Re: [DISCUSS] Cordova Doc Release

2019-03-18 Thread Jan Piotrowski
https://github.com/apache/cordova-docs/blob/master/doc/working-on-docs.md

Am Mo., 18. März 2019 um 14:23 Uhr schrieb Bryan Ellis :
>
> Yeah.
>
> As far as I know, there are no release processes for docs. This I knew.
>
> I suspect there is a manual process that needs to be performed and may not
> be documented.
> For example, converting dev docs to a version of 9.x and setting it as the
> latest.
>
> The discussion was only there so people who knew of missing documents from
> all the recent changes in various location could start adding.
>
> But yes, as Jan said, we only need to merge and it will be released.
>
> On Mon, Mar 18, 2019 at 6:22 PM Jan Piotrowski  wrote:
>
> > As Julio noticed, there is no release process for docs - what is
> > merged is deployed.
> >
> > But yes, Cordova Android is missing the new API levels and probably
> > some documentation on the new features.
> >
> > -J
> >
> >
> > Am Mo., 18. März 2019 um 09:43 Uhr schrieb julio cesar sanchez
> > :
> > >
> > > I don’t think the docs follow the release process, or at least I’ve never
> > > seen a docs release vote/discuss thread.
> > >
> > > El lunes, 18 de marzo de 2019, Bryan Ellis  escribiĂł:
> > >
> > > > Does anyone have any reason to delay the release of Cordova Docs?
> > > > Any outstanding documents to write and land?
> > > >
> > > > If not, I will start the release tomorrow.
> > > >
> > > > Please note that:
> > > > - Cordova Docs does not have an official NPM package release version.
> > > > - The current npm package is `0.0.1` but not published nor associated
> > to a
> > > > release version of Docs.
> > > > - Last GH tag was 5.1.1 (2015) but also not following the official
> > `rel/`
> > > > tag schema.
> >
> > -
> > 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 Doc Release

2019-03-18 Thread Jan Piotrowski
As Julio noticed, there is no release process for docs - what is
merged is deployed.

But yes, Cordova Android is missing the new API levels and probably
some documentation on the new features.

-J


Am Mo., 18. März 2019 um 09:43 Uhr schrieb julio cesar sanchez
:
>
> I don’t think the docs follow the release process, or at least I’ve never
> seen a docs release vote/discuss thread.
>
> El lunes, 18 de marzo de 2019, Bryan Ellis  escribiĂł:
>
> > Does anyone have any reason to delay the release of Cordova Docs?
> > Any outstanding documents to write and land?
> >
> > If not, I will start the release tomorrow.
> >
> > Please note that:
> > - Cordova Docs does not have an official NPM package release version.
> > - The current npm package is `0.0.1` but not published nor associated to a
> > release version of Docs.
> > - Last GH tag was 5.1.1 (2015) but also not following the official `rel/`
> > tag schema.

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



Re: [DISCUSS] Cordova Lib 9.0.0 Release

2019-03-15 Thread Jan Piotrowski
The PR is marked as Work in Progress. If you want it to get reviewed
and merged you should remove that.

Am Fr., 15. März 2019 um 13:18 Uhr schrieb Oliver Salzburg
:
>
> I really think we should get #680[1] merged before the release.
>
> It should be good in a moment.
>
> [1]: https://github.com/apache/cordova-lib/pull/680
>
> On 14/03/2019 07:31, Bryan Ellis wrote:
> > Does anyone have any reason to delay the Cordova Lib release?
> > Any outstanding patches to land?
> >
> > If not, I will start the release tomorrow.
> >
> > The versions to be released are:
> > cordova-lib@9.0.0
> >
>
> -
> 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: [VOTE] Cordova-Windows 7.0.0 Release

2019-03-05 Thread Jan Piotrowski
+1

- CI is green
- changes make sense

Am Di., 5. März 2019 um 10:33 Uhr schrieb Jesse :
>
> +1
>
> - Ran coho verify-archive
> - CI was green
>
>
> @purplecabbage
> risingj.com
>
>
> On Mon, Mar 4, 2019 at 11:54 PM Bryan Ellis  wrote:
>
> > Please review and vote on this Windows Release v7.0.0
> > by replying to this email (and keep discussion on the DISCUSS thread)
> >
> > Release issue: https://github.com/apache/cordova/issues/10
> >
> > The archive has been published to dist/dev:
> > https://dist.apache.org/repos/dist/dev/cordova/GH-10
> >
> > The package was published from its corresponding git tag:
> > cordova-windows: 7.0.0 (0e7587ad29)
> >
> > Note that you can test it out via:
> >
> > cordova platform add https://github.com/apache/cordova-windows#7.0.0
> >
> > Upon a successful vote I will upload the archive to dist/, publish it to
> > npm, and post the blog post.
> >
> > Voting guidelines:
> > https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
> >
> > Voting will go on for a minimum of 48 hours.
> >
> > I vote +1:
> > * Ran coho audit-license-headers over the relevant repos
> > * Ran coho check-license to ensure all dependencies and subdependencies
> > have Apache-compatible licenses
> > * Ensured continuous build was green when repo was tagged
> > * NPM Audit
> > * NPM Tests

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



Re: [VOTE] Cordova-Electron 1.0.1 Patch Release

2019-03-05 Thread Jan Piotrowski
+1

* CI is green
* changes make sense

Am Di., 5. März 2019 um 07:14 Uhr schrieb Ken Naito :
>
> +1
>
> * coho verify-archive OK
> * coho verify-tags OK  (except for confirming signature owner)
> * The last commit 8649e607d605f8c705b983d7042aa73ba7da1c4f passes CI tests.
>
>
> Note that I added
>   {
>  title: 'Electron',
>  versions: ['1.0'],
>  id: 'electron',
>  repoName: 'cordova-electron',
>  jiraComponentName: 'cordova-electron'
>  }
> in repoutils.js in cordova-coho to use coho commands for cordova-electron.
>
>
>
> On 2019/03/04 17:49, Bryan Ellis wrote:
> >  cordova-electron: 1.0.1 (a8c677ed8b)
>
>
> -
> 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: [VOTE] Cordova-Android 8.0.0 Release

2019-02-14 Thread Jan Piotrowski
+1

RELEASENOTES.md is missing the 7.1.x releases because they weren't merged
back from the release branch, but that does not block the release and can
just be fixed on master now.

- installed the platform with current CLI and added a few plugins
- build and ran an app on an Nexus 5
- CI is green, ohther stuff looks in order as well


Am Do., 14. Feb. 2019 um 15:18 Uhr schrieb Chris Brody <
chris.br...@gmail.com>:

> +1
>
> cordova-android@d5069b1030 has green build on GitHub (8.0.x branch)
>
> On Wed, Feb 13, 2019 at 9:07 PM Bryan Ellis  wrote:
> >
> > Please review and vote on this Android Release v8.0.0
> > by replying to this email (and keep discussion on the DISCUSS thread)
> >
> > Release issue: https://github.com/apache/cordova/issues/10
> >
> > The archive has been published to dist/dev:
> > https://dist.apache.org/repos/dist/dev/cordova/GH-10
> >
> > The package was published from its corresponding git tag:
> > cordova-android: 8.0.0 (d5069b1030)
> >
> > Note that you can test it out via:
> >
> > cordova platform add https://github.com/apache/cordova-android#8.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
> > * NPM Audit
> > * Executed Individual Test Steps in Following Order
> >   * npm run eslint
> >   * sudo npm run unit-test
> >   * npm run e2e-tests
> >   * npm run java-unit-tests
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>


Re: [DISCUSS] Cordova-Android Release

2019-02-08 Thread Jan Piotrowski
Let me correct my question then:
Why are those blocking and can not be added in a future major
cordova-android release (with an accompanying CLI release that adds
this as the new default android version to be installed if that is
still necessary) when those changes are merged?

-J


Am Fr., 8. Feb. 2019 um 12:30 Uhr schrieb julio cesar sanchez
:
>
> Unless we find a way of enabling/disabling Android X support, it's going to
> be a breaking change for all plugins using using the old way, so we can't
> do that in a 8.1 release
>
> El vie., 8 feb. 2019 a las 12:03, Jan Piotrowski ()
> escribiĂł:
>
> > I am not sure I follow:
> > Why are those blocking and can not be added with a quick 8.1 when
> > those changes are merged?
> >
> > -J
> >
> > Am Fr., 8. Feb. 2019 um 01:55 Uhr schrieb Chris Brody <
> > chris.br...@gmail.com>:
> > >
> > > I think the major blockers are AndroidX and bug 508. I already
> > > proposed a quick fix solution for 508. For AndroidX I think we need to
> > > do a little more analysis and testing.
> > >
> > > Unfortunately I cannot promise much on my part due to some other
> > > priorities. I will try to take another look in the next few days, no
> > > guarantees though.
> > >
> > > On Thu, Feb 7, 2019 at 2:22 PM Chris Brody 
> > wrote:
> > > >
> > > > Update coming later today. I think there are still a number of
> > > > blockers that we need to get resolved.
> > > >
> > > > On Thu, Feb 7, 2019 at 3:48 AM Bryan Ellis 
> > wrote:
> > > > >
> > > > > Can I get an update on this?
> > > > > Is there anyone still working on any blockers that need to be
> > finished
> > > > > before release?
> > > > > Can we continue with this release?
> > > > >
> > > > >
> > > > > On Sat, Jan 19, 2019 at 6:49 AM Chris Brody 
> > wrote:
> > > > >
> > > > > > I would agree with Julio that we should verify androidx support
> > before we
> > > > > > finish the next major release. I don't expect we will have to make
> > any
> > > > > > fixes on cordova-android for androidx support. Issues for
> > reference:
> > > > > > * https://github.com/apache/cordova/issues/69
> > > > > > * https://github.com/apache/cordova-android/issues/565
> > > > > >
> > > > > > I just raised WIP PR
> > https://github.com/apache/cordova-android/pull/633 to
> > > > > > resolve bug 508. I hope to fix the tests within the next 1-2 days.
> > > > > >
> > > > > > I think we should also try to resolve the following issues before
> > the next
> > > > > > major release:
> > > > > > * https://github.com/apache/cordova-android/issues/629 - issue
> > with
> > > > > > Android
> > > > > > Studio 3.2 & 3.3
> > > > > > * https://github.com/apache/cordova-android/issues/623 - fix
> > logging of
> > > > > > Java version (a PR was already proposed)
> > > > > >
> > > > > > I think it would be nice but not absolutely necessary to resolve
> > the
> > > > > > following issue as well:
> > > > > > * https://github.com/apache/cordova-android/issues/617 - support
> > > > > > ANDROID_SDK_ROOT in addition to ANDROID_HOME which is now
> > deprecated
> > > > > > * https://github.com/apache/cordova-android/issues/634 - update
> > Gradle
> > > > > > classpath for Android Studio 3.3
> > > > > > * review & merge the following PRs:
> > > > > >   - https://github.com/apache/cordova-android/pull/632 - ignore
> > more
> > > > > > Gradle
> > > > > > build artifacts in Android project
> > > > > >   - https://github.com/apache/cordova-android/pull/635 - ignore
> > Android
> > > > > > Studio .idea files in Android project
> > > > > >
> > > > > > On Fri, Jan 18, 2019 at 9:09 AM julio cesar sanchez <
> > > > > > jcesarmob...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > As it's going to be a major release, I think we should look a
> > bit more
> > > > > > into
> > > > > > > Android X before doing a major release, just in c

Re: [DISCUSS] Cordova-Android Release

2019-02-08 Thread Jan Piotrowski
I am not sure I follow:
Why are those blocking and can not be added with a quick 8.1 when
those changes are merged?

-J

Am Fr., 8. Feb. 2019 um 01:55 Uhr schrieb Chris Brody :
>
> I think the major blockers are AndroidX and bug 508. I already
> proposed a quick fix solution for 508. For AndroidX I think we need to
> do a little more analysis and testing.
>
> Unfortunately I cannot promise much on my part due to some other
> priorities. I will try to take another look in the next few days, no
> guarantees though.
>
> On Thu, Feb 7, 2019 at 2:22 PM Chris Brody  wrote:
> >
> > Update coming later today. I think there are still a number of
> > blockers that we need to get resolved.
> >
> > On Thu, Feb 7, 2019 at 3:48 AM Bryan Ellis  wrote:
> > >
> > > Can I get an update on this?
> > > Is there anyone still working on any blockers that need to be finished
> > > before release?
> > > Can we continue with this release?
> > >
> > >
> > > On Sat, Jan 19, 2019 at 6:49 AM Chris Brody  wrote:
> > >
> > > > I would agree with Julio that we should verify androidx support before 
> > > > we
> > > > finish the next major release. I don't expect we will have to make any
> > > > fixes on cordova-android for androidx support. Issues for reference:
> > > > * https://github.com/apache/cordova/issues/69
> > > > * https://github.com/apache/cordova-android/issues/565
> > > >
> > > > I just raised WIP PR https://github.com/apache/cordova-android/pull/633 
> > > > to
> > > > resolve bug 508. I hope to fix the tests within the next 1-2 days.
> > > >
> > > > I think we should also try to resolve the following issues before the 
> > > > next
> > > > major release:
> > > > * https://github.com/apache/cordova-android/issues/629 - issue with
> > > > Android
> > > > Studio 3.2 & 3.3
> > > > * https://github.com/apache/cordova-android/issues/623 - fix logging of
> > > > Java version (a PR was already proposed)
> > > >
> > > > I think it would be nice but not absolutely necessary to resolve the
> > > > following issue as well:
> > > > * https://github.com/apache/cordova-android/issues/617 - support
> > > > ANDROID_SDK_ROOT in addition to ANDROID_HOME which is now deprecated
> > > > * https://github.com/apache/cordova-android/issues/634 - update Gradle
> > > > classpath for Android Studio 3.3
> > > > * review & merge the following PRs:
> > > >   - https://github.com/apache/cordova-android/pull/632 - ignore more
> > > > Gradle
> > > > build artifacts in Android project
> > > >   - https://github.com/apache/cordova-android/pull/635 - ignore Android
> > > > Studio .idea files in Android project
> > > >
> > > > On Fri, Jan 18, 2019 at 9:09 AM julio cesar sanchez <
> > > > jcesarmob...@gmail.com>
> > > > wrote:
> > > >
> > > > > As it's going to be a major release, I think we should look a bit more
> > > > into
> > > > > Android X before doing a major release, just in case we need to do 
> > > > > major
> > > > > changes.
> > > > > In the issue related to Android X, I commented that we didn't have the
> > > > > gradle.properties file, but in the linked PR I saw it's going to be
> > > > > generated by the tooling now, so should be easier to just write to it
> > > > with
> > > > > whatever is needed, and probably make it opt-in for now as it's not 
> > > > > clear
> > > > > if using Android X will prevent old plugins from working.
> > > > > Or is the gradle.properties file supposed to be managed by the user
> > > > > somehow?
> > > > >
> > > > > El vie., 18 ene. 2019 a las 15:02, Chris Brody 
> > > > > ()
> > > > > escribiĂł:
> > > > >
> > > > > > I am investigating a quick solution for the bug, hope to have 
> > > > > > something
> > > > > > today.
> > > > > >
> > > > > > On Fri, Jan 18, 2019, 8:42 AM Chris Brody  > > > wrote:
> > > > > >
> > > > > > > The bug was introduced by new code that was added to both master 
> > > > > > > and
> > > > > > 7.1.4.
> > > > &

Re: [DISCUSS] Cordova-Android Release

2019-01-18 Thread Jan Piotrowski
Is this a new bug introduced by the new code that would be released?
If not, there is no reason to stop a release of that (good) code. As
soon as a fix for this bug is available, we can release it as a follow
up release (patch, minor, major - whatever appropriate).

-J

Am Fr., 18. Jan. 2019 um 13:18 Uhr schrieb Chris Brody :
>
> I do not think we should make a new cordova-android release before we can
> resolve https://github.com/apache/cordova-android/issues/508
>
> I think it is a pretty bad bug. I would be happy to explain further if
> needed.
>
> On Fri, Jan 18, 2019 at 12:56 AM Bryan Ellis  wrote:
>
> > Does anyone have any reason to delay a cordova-android platform release?
> > Any outstanding patches to land?
> >
> > If not, I will start the release process shortly.
> >

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



Re: Contribution Newbie

2019-01-10 Thread Jan Piotrowski
Hey Martina,

what areas are you most interested in? Code or documentation?
What is your experience with JS software, besides writing Cordova apps?

If you are looking for a way to contribute with comparatively little setup:
We have a big backlog of Pull Requests for core plugins. Those usually
need understanding the problem, testing the solution/PR, possibly
communicating with the creator of the PR (understanding the solution,
getting them to add documentation or update the code), and finally
leaving a GitHub review if this should be merged or not (with
documentation on how and what you tested).

Best,
Jan

Am Do., 10. Jan. 2019 um 20:42 Uhr schrieb Martina M
:
>
> Hi All,
>
> My name is Martina and I have been building apps with Cordova for last 8 or
> so years. I am looking for some opportunities to contribute to open source
> projects and I thought I might be able to help.
>
> I have read the guidelines already. If there is an issue that you think
> would be a good start for me please let me know.
>
> Best wishes,
> Martina
>
> 
> Virus-free.
> www.avast.com
> 
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

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



Re: Latest cordova-android version not in maven repository

2018-12-17 Thread Jan Piotrowski
Any reason you skipped this documented release step?
https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md#android-only-uploading-to-bintray

> Also can someone explain the use case for publishing on Maven?

Cordova Android is made available via Bintray/Maven so it can be be
required and used via that distribution method.

-J


Am Mo., 17. Dez. 2018 um 14:48 Uhr schrieb Chris Brody <
chris.br...@gmail.com>:

> I published the last 2 releases, don't have much time this week to look
> into Maven. Any chance someone else can do this?
>
> Also can someone explain the use case for publishing on Maven?
>
> On Mon, Dec 17, 2018, 7:57 AM julio cesar sanchez  wrote:
>
> > Not sure if we missed some step on latest cordova-android releases, or
> > if somebody else is publishing after releases, but 7.1.3 and 7.1.4 are
> > not available on maven.
> >
> > Latest is 7.1.2
> > https://mvnrepository.com/artifact/org.apache.cordova/framework/7.1.2
> >
>


Re: [New Feature] Change WebSettings of the WebView by config file

2018-12-12 Thread Jan Piotrowski
> Googling "setAllowFileAccess security issue" show many results...

If your follow up email is about this, then you are posting/asking in the
wrong email thread. This one here was about "Change WebSettings of the
WebView by config file".
Allowing setAllowFileAccess to be configurable can be done with a
one-off-feature and doesn't need this big change.

(Sorry to be pedantic here, but it doesn't make a lot of sense to discuss
feature A in a thread about feature B)

-J

Am Mi., 12. Dez. 2018 um 16:28 Uhr schrieb MALEYRIE Stephane (AIM Services)
:

> So, is anybody is interested with this feature ?
>
> Googling "setAllowFileAccess security issue" show many results...
>
> It may interst other people...
>
> > I told them to send the mail first to discuss the new feature, nobody
> has said anything about if we want it or not.
> > I think we should agree before any issue is created.
>
> > El lun., 10 dic. 2018 a las 17:54, Chris Brody ()
> > escribiĂł:
>
> > And you can find Cordova email archive in:
> > https://lists.apache.org/list.html?dev@cordova.apache.org
> > On Mon, Dec 10, 2018 at 11:45 AM Jan Piotrowski 
> > wrote:
> > >
> > > Yes, to create a GitHub issue is the correct way to suggest a feature.
> > > Please include a link to the lists.apache.org of this thread for the
> > > related discussion.
> > >
> > > -J
> > > Am Mo., 10. Dez. 2018 um 17:18 Uhr schrieb MALEYRIE Stephane (AIM
> > > Services) :
> > > >
> > > > Hello,
> > > >
> > > > To conclude, can you tell me the best way to ask the developement
> > > > of
> > this new feature ?
> > > > Is it to create a github issue ?
> > > >
> > > > I'd like to post this, if you see somthing to change, please, let
> > > > me
> > know :
> > > >
> > > > Subject :
> > > > [New Feature] Allow to change WebSettings of the WebView by config
> > file, or at least, the allowFileAccess attributes
> > > >
> > > > Message :
> > > > Hello,
> > > >
> > > > Is it possible to develop a new feature, to allow changing
> > > > WebSettings
> > of the WebView by config file, or at least, allowFileAccess attributes
> > > >
> > > > Currently, the only way is to hard code settings config here :
> > https://github.com/apache/cordova-android/blob/6.4.x/framework/src/org
> > /apache/cordova/engine/SystemWebViewEngine.java#L152
> > > >
> > > > It would be usefull if we can configure any settings of
> > > > WebSettings
> > class :
> > https://developer.android.com/reference/android/webkit/WebSettings
> > > > Maybe by using preference in config.xml ?
> > > >
> > > > Thanks.
> > > >
> > > > Stéphane
> > > >
> > > > Related mails :
> > > >
> > https://lists.apache.org/thread.html/5a6cfdb0795655ed8d8d411e1ad2a5440
> > 7094ba54af7dd11bb05c7b2@%3Cdev.cordova.apache.org%3E
> > > >
> > > > --
> > > >
> > > > Thanks again
> > > >
> > > >
> > > > > I think this should be possible with preference tags in the
> > config.xml, we should be able to read them and set those values to
> > true or false, being the default the current one so it's not a breaking
> change.
> > > >
> > > > > El jue., 6 dic. 2018 a las 16:45, Jan Piotrowski (<
> > piotrow...@gmail.com>)
> > > > > escribiĂł:
> > > >
> > > > > > I read through the other threads. [...]
> > > > >
> > > > > Please reply to questions from other threads in these threads
> > > > > instead of interlinking two discussions that are about related,
> > > > > but different things. Thanks.
> > > > >
> > > > >
> > > > >
> > > > > -J
> > > > >
> > > > >
> > > > > Am Do., 6. Dez. 2018 um 16:16 Uhr schrieb Chris Brody <
> > > > > chris.br...@gmail.com>:
> > > > > >
> > > > > > > After a few questions about changing an attribute of the
> > > > > > > WebSettings
> > > > > of the WebView (setAllowFileAccess) here :
> > > > >
> > https://lists.apache.org/thread.html/3b97152bf089423292ba039bc690d923e
> > > > > 438c4f902c40c2714faff90@%3Cdev.cordova.apache.org%3E
>

Re: [New Feature] Change WebSettings of the WebView by config file

2018-12-10 Thread Jan Piotrowski
Yes, to create a GitHub issue is the correct way to suggest a feature.
Please include a link to the lists.apache.org of this thread for the
related discussion.

-J
Am Mo., 10. Dez. 2018 um 17:18 Uhr schrieb MALEYRIE Stephane (AIM
Services) :
>
> Hello,
>
> To conclude, can you tell me the best way to ask the developement of this new 
> feature ?
> Is it to create a github issue ?
>
> I'd like to post this, if you see somthing to change, please, let me know :
>
> Subject :
> [New Feature] Allow to change WebSettings of the WebView by config file, or 
> at least, the allowFileAccess attributes
>
> Message :
> Hello,
>
> Is it possible to develop a new feature, to allow changing WebSettings of the 
> WebView by config file, or at least, allowFileAccess attributes
>
> Currently, the only way is to hard code settings config here : 
> https://github.com/apache/cordova-android/blob/6.4.x/framework/src/org/apache/cordova/engine/SystemWebViewEngine.java#L152
>
> It would be usefull if we can configure any settings of WebSettings class : 
> https://developer.android.com/reference/android/webkit/WebSettings
> Maybe by using preference in config.xml ?
>
> Thanks.
>
> Stéphane
>
> Related mails :
> https://lists.apache.org/thread.html/5a6cfdb0795655ed8d8d411e1ad2a54407094ba54af7dd11bb05c7b2@%3Cdev.cordova.apache.org%3E
>
> --
>
> Thanks again
>
>
> > I think this should be possible with preference tags in the config.xml, we 
> > should be able to read them and set those values to true or false, being 
> > the default the current one so it's not a breaking change.
>
> > El jue., 6 dic. 2018 a las 16:45, Jan Piotrowski ()
> > escribiĂł:
>
> > > I read through the other threads. [...]
> >
> > Please reply to questions from other threads in these threads instead
> > of interlinking two discussions that are about related, but different
> > things. Thanks.
> >
> >
> >
> > -J
> >
> >
> > Am Do., 6. Dez. 2018 um 16:16 Uhr schrieb Chris Brody <
> > chris.br...@gmail.com>:
> > >
> > > > After a few questions about changing an attribute of the
> > > > WebSettings
> > of the WebView (setAllowFileAccess) here :
> > https://lists.apache.org/thread.html/3b97152bf089423292ba039bc690d923e
> > 438c4f902c40c2714faff90@%3Cdev.cordova.apache.org%3E
> > > > And :
> > https://lists.apache.org/thread.html/1865cda074ad5d741bd19d01a56cc5b2b
> > 4ac6e2a599d31b34f89eed6@%3Cdev.cordova.apache.org%3E
> > > > (sorry for bad reply of my second mail who lost historic)
> > >
> > > I read through the other threads. The two problems right now are
> > > that cordova-plugin-fcm does not work with cordova-android@7 and you
> > > need to do settings.setAllowFileAccess(false).
> > >
> > > I think you are right to maintain a private fork of
> > > cordova-android@6 for now. I recommend that you guys watch the
> > > issues and updates on our cordova-android project for anything
> > > important. There were npm security audit issues on some old
> > > dependencies, which we fixed in cordova-android@7.
> > >
> > > > I'd like to ask if it is possible to develop a new feature, to
> > > > allow
> > changing WebSettings of the WebView by config file.
> > >
> > > That should be possible. I am personally not so familiar with the
> > > configuration part, would need some time to figure out how we could
> > > do this. I would favor a process of identifying the use cases before
> > > going deeper, as Jan asked.
> > >
> > > 
> > > - 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



Mass PR creation support

2018-12-07 Thread Jan Piotrowski
Hi.

For several open tasks (e.g. updating `package.json` across many
repos, distributing the GitHub Issue and PR templates, updating the
plugin CI configuration) we will have to change files in many
repositories and then create a PR (which means the changes have to be
applied in a new branch or even fork) on Github to be reviewed and
merged.

Currently we don't have and I don't know of any proper tooling for this.
We have cordova-coho, but that can "only" check out, update and
commit/push repositories.

Do you know of any software, tools or libraries that might help here?
If not, can you maybe help to get this implemented in coho? I created
https://github.com/apache/cordova-coho/issues/222 to track this.

Thanks,
Jan

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



Re: Nomination for a new chair for Apache Cordova

2018-12-07 Thread Jan Piotrowski
+1

Thanks to you both!
Am Fr., 7. Dez. 2018 um 10:05 Uhr schrieb julio cesar sanchez
:
>
> +1
>
> And thanks to you for all this years and to him for taking over
>
> El El vie, 7 dic 2018 a las 8:02, Toplak Daniel 
> escribiĂł:
>
> > Hello Shazron,
> >
> > thank you for your hard work the last few years and I will totally agree
> > with the nomination of Jesse :-)
> > +1
> >
> > GrĂĽĂźe / Regards
> > Daniel Toplak
> > Head of Mobile Development
> >
> > > -UrsprĂĽngliche Nachricht-
> > > Von: Shazron 
> > > Gesendet: Friday, December 7, 2018 03:30
> > > An: dev@cordova.apache.org
> > > Betreff: Nomination for a new chair for Apache Cordova
> > >
> > > Hello beloved Community!
> > > I have been the chair of Apache Cordova since around April 2014 (~4.5
> > years).
> > >
> > > The duties are mostly administrative: board reports, PMC management etc.
> > Some
> > > of it is listed here in the README:
> > > https://github.com/apache/cordova-apache-board-reports
> > >
> > > I think it is time for new leadership. I have decided to resign my
> > duties as the
> > > Apache Cordova chair, hopefully for the upcoming new year of 2019.
> > >
> > > I nominate Jesse MacFadyen as the next chair. Jesse has been with me at
> > the start
> > > when Cordova was PhoneGap. Although we didn't give birth to it, we
> > helped work
> > > on improving Cordova from being an infant to adulthood (together with
> > our great
> > > team), particularly on cordova-ios.
> > > 10 years is adulthood in software!
> > >
> > > He has also contributed greatly to the other platforms and tooling,
> > particularly
> > > cordova-windows. He has the most experience with helping run the Cordova
> > > project out of the remaining active contributors.
> > >
> > > As an Apache Member (https://www.apache.org/foundation/members.html)
> > > he also understands and helps uphold 'The Apache Way'
> > > (https://www.apache.org/foundation/how-it-works.html) and will be a
> > great liaison
> > > with the Board.
> > >
> > > I'm not going anywhere and I will still contribute to the project in my
> > areas of
> > > expertise.
> > >
> > > Thank you.
> > >
> > > -
> > > 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: [New Feature] Change WebSettings of the WebView by config file

2018-12-06 Thread Jan Piotrowski
> I read through the other threads. [...]

Please reply to questions from other threads in these threads instead
of interlinking two discussions that are about related, but different
things. Thanks.



-J


Am Do., 6. Dez. 2018 um 16:16 Uhr schrieb Chris Brody :
>
> > After a few questions about changing an attribute of the WebSettings of the 
> > WebView (setAllowFileAccess) here : 
> > https://lists.apache.org/thread.html/3b97152bf089423292ba039bc690d923e438c4f902c40c2714faff90@%3Cdev.cordova.apache.org%3E
> > And : 
> > https://lists.apache.org/thread.html/1865cda074ad5d741bd19d01a56cc5b2b4ac6e2a599d31b34f89eed6@%3Cdev.cordova.apache.org%3E
> > (sorry for bad reply of my second mail who lost historic)
>
> I read through the other threads. The two problems right now are that
> cordova-plugin-fcm does not work with cordova-android@7 and you need
> to do settings.setAllowFileAccess(false).
>
> I think you are right to maintain a private fork of cordova-android@6
> for now. I recommend that you guys watch the issues and updates on our
> cordova-android project for anything important. There were npm
> security audit issues on some old dependencies, which we fixed in
> cordova-android@7.
>
> > I'd like to ask if it is possible to develop a new feature, to allow 
> > changing WebSettings of the WebView by config file.
>
> That should be possible. I am personally not so familiar with the
> configuration part, would need some time to figure out how we could do
> this. I would favor a process of identifying the use cases before
> going deeper, as Jan asked.
>
> -
> 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: [New Feature] Change WebSettings of the WebView by config file

2018-12-06 Thread Jan Piotrowski
What other use cases besides `setAllowFileAccess` do you see here?

-J

Am Do., 6. Dez. 2018 um 14:36 Uhr schrieb MALEYRIE Stephane (AIM
Services) :
>
> Hello,
>
> After a few questions about changing an attribute of the WebSettings of the 
> WebView (setAllowFileAccess) here : 
> https://lists.apache.org/thread.html/3b97152bf089423292ba039bc690d923e438c4f902c40c2714faff90@%3Cdev.cordova.apache.org%3E
> And : 
> https://lists.apache.org/thread.html/1865cda074ad5d741bd19d01a56cc5b2b4ac6e2a599d31b34f89eed6@%3Cdev.cordova.apache.org%3E
> (sorry for bad reply of my second mail who lost historic)
>
> I'd like to ask if it is possible to develop a new feature, to allow changing 
> WebSettings of the WebView by config file.
>
> Currently, the only way is to hard code settings config here : 
> https://github.com/apache/cordova-android/blob/6.4.x/framework/src/org/apache/cordova/engine/SystemWebViewEngine.java#L152
>
> It would be usefull il we can configure any settings of WebSettings class : 
> https://developer.android.com/reference/android/webkit/WebSettings
> Maybe with a dedicated config file, or plugged in the config.xml ?
>
> I have never worked on gradle project or Android Studio project, so i'm 
> limitted. I'm using cordova-android on an ionic3 application
> Anybody in the community could help ? And What do you think about the idea ?
>
> Thanks to all.
>
> Stéphane

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



Re: [dev] Cordova-Android Gradle improvements?

2018-12-04 Thread Jan Piotrowski
Aside:
By definition WIP (Work in Progress) pull requests should not be
reviewed. If someone ignores that, I think it is fair to dismiss all
the reviews without further comment.

-J
Am Di., 4. Dez. 2018 um 19:16 Uhr schrieb Chris Brody :
>
> By "user-defined Gradle files" I meant what someone can put into
> build-extras.gradle. By supporting user-editable build-extras.gradle
> in the generated Android project we encounter some possible issues
> such as:
> * supporting project structure change, where we already encountered
> 
> * user needs to install cordova-android update
> * user needs to regenerate platforms/android for any reason
>
> I hope we can find a better solution somehow.
>
> I was wondering if we should consider getting some of these
> enhancements into Cordova 9 or not. I would not personally favor
> holding up Cordova 9 for this kind of enhancement.
>
> I would also favor opening an issue on GitHub where we can discuss and
> track this item more easily, leaving it up to you.
>
> I think you are right not to open a WIP PR until you have enough
> confidence for possible feedback & discussion. You *could* publish an
> informal WIP branch if you like.
>
> I am personally not a super Gradle expert so I would probably just
> give feedback on quality of structure, "how it looks", etc. Thanks for
> your efforts on this.
> On Tue, Dec 4, 2018 at 12:54 PM Darryl Pogue  wrote:
> >
> > I'm experimenting with refactoring the way Cordova's gradle files are
> > set up. Partly to resolve issues around the availability of Cordova
> > helper methods[1], the new app bundles features[2], Kotlin support[3],
> > and to investigate options for making the setting of build-time
> > variables (like min SDK versions) more consistent.[4]
> >
> > What I can tell you from my initial skimming of the code on Sunday is
> > that a lot of the plugin handling is done in a way that tried to
> > preserve as much as possible from the existing Ant-based project
> > structure, such as reading from project.properties files and building
> > up references to inject into the build.gradle file from those.
> >
> > I'm not sure what you mean by "it should be possible for user-defined
> > Gradle files to be configured outside the generated cordova-android
> > project". Plugins can provide their own gradle files to add things
> > like libraries and override ext variables, but those need to get
> > included in the app project's build because the plugin source files
> > themselves are included in the app project's build.
> >
> > I can try to open a WIP PR for the gradle refactoring I'm doing, but
> > currently it doesn't work and I'm a bit worried that it's going to end
> > up held up forever in review with a bunch of requested changes to
> > stuff that doesn't even work yet.
> > I'm not making changes to the existing gradle files, I'm literally
> > deleting them all and rewriting them to try to make them adhere better
> > to gradle conventions, and it's an experiment that might totally
> > backfire.
> >
> > [1] https://github.com/apache/cordova-android/pull/438#discussion_r216195552
> > [2] https://github.com/apache/cordova-android/issues/596
> > [3] https://github.com/apache/cordova-android/pull/441
> > [4] https://github.com/apache/cordova-android/issues/508
> >
> > On Tue, Dec 4, 2018 at 9:15 AM Chris Brody  wrote:
> > >
> > > I think it should be possible for user-defined Gradle files to be
> > > configured outside the generated cordova-android project to avoid
> > > issues we have encountered such as changing project structure and
> > > cordova-android upgrades. While it would be possible for a user to
> > > make a custom plugin with a custom Gradle file this may not be
> > > convenient for all Cordova Android apps.
> > >
> > > And it would be ideal if we could somehow alleviate the need for
> > > PLUGIN GRADLE EXTENSIONS START / PLUGIN GRADLE EXTENSIONS END
> > > placeholder comments as discussed in
> > > . Maybe we could
> > > move the plugin Gradle extensions into a separate file?
> > >
> > > -
> > > 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: [PRs] "Deprecation and Archiving Policy"

2018-12-04 Thread Jan Piotrowski
Thank you for your reviews and approvals @raphinesse, @erisu and @Menardi.

This is now all merged and available:
https://cordova.apache.org/deprecation_policy.html
https://github.com/apache/cordova-contribute/blob/master/deprecation.md

After feedback from Jesse I also moved the list of deprecations to a
new location which makes a lot more sense:
https://github.com/apache/cordova/blob/master/deprecated.md
(the repo cordova-deprecated I mentioned above is gone)

Next step: I will create some PRs that add the deprecation notice to
our already deprecated components.

-J

Am Fr., 30. Nov. 2018 um 17:51 Uhr schrieb Jan Piotrowski
:
>
> I just finished revising my PRs regarding the deprecation and
> archiving of repositories. Finishing this is needed to actually be
> able to go ahead and vote on the archival of the first repositories.
>
> 1. First one is a general "Deprecation and Archiving Policy" that
> would be available on our website at
> https://cordova.apache.org/deprecation_policy.html:
>
> PR: https://github.com/apache/cordova-docs/pull/878
> Preview: 
> https://github.com/apache/cordova-docs/blob/b8a7c650e97e3e0251464d7085b097032af16fb6/www/deprecation_policy.md#meaning-of-deprecation
>
> 2. Second are the contributor targeted instructions that would live in
> https://github.com/apache/cordova-contribute. This includes the
> individual steps, but also the templates for the deprecation notice to
> places in README of the deprecated component:
>
> PR: https://github.com/apache/cordova-contribute/pull/2
> Preview: 
> https://github.com/apache/cordova-contribute/blob/e690e4d098b3c95f997a50ec2d060b51a905993f/deprecation.md
>
> Additionally to these two PRs, I went ahead and created
> https://github.com/apache/cordova-deprecated which contains a list of
> all our already deprecated components. For the plugins I added the
> necessary information already. That way we can achive a repository
> (making its README readonly) and still update links to alternatives
> etc.
>
> Please look over these 2 PRs I linked above, leave comments and
> reviews [1]. Thanks!
>
> Best,
> Jan
>
> [1] 
> https://help.github.com/articles/reviewing-proposed-changes-in-a-pull-request/#submitting-your-review

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



Re: How to disable in Android Webview, the WebSettings attributes "AllowFileAccess" in cordova-android ?

2018-12-04 Thread Jan Piotrowski
Hi Stéphane,

there is a newer version of cordova-android available: 7.x.x -
currently 7.1.4. That means that we, the volunteer development team,
won't do any more updates to the 6.x branch. So even if we implement
any new features here, they will only get released for 7.x.
Any particular reason why you are still using 6.4.0? The plugin
compatibility got much better in the last few releases, maybe try
7.1.4 if it works for you.

That being said, the only thing regarding file access seems to be here:
https://github.com/apache/cordova-android/blob/c0c3b769f2260870d90da75965985070831dcd1d/framework/src/org/apache/cordova/engine/SystemWebViewEngine.java#L184
This is not configurable in any way right now.

Did I understand correctly that you are asking for
https://developer.android.com/reference/android/webkit/WebSettings.html#setAllowFileAccess(boolean)?
Can you maybe elaborate a bit on "we don't use this feature that may
introduce security issue."? Maybe this is worth being implemented
generally.

Best,
Jan

PS: I have no experience if or if not this is possible to be changed
in a plugin - someone else has to weigh in on that.
Am Di., 4. Dez. 2018 um 14:38 Uhr schrieb MALEYRIE Stephane (AIM
Services) :
>
> Hello,
>
> After an Android security audit, we need to disable in the WebView, the 
> WebSettings attributes "AllowFileAccess" because we don't use this feature 
> that may introduce security issue.
>
> I'm developing an ionic3 application based on Cordova-android 6.4.0
>
> The Webview initialisation code seems to be here : 
> org.apache.cordova.engine.SystemWebViewEngine
> All the attributes setting like AllowFileAccess  are in the 
> initWebViewSettings method 
> (https://github.com/apache/cordova-android/blob/6.4.x/framework/src/org/apache/cordova/engine/SystemWebViewEngine.java#L147).
> How can I change the settings for AllowFileAccess without editing the code ?
> Is it possible to implements something, so i can configure WebSettings in 
> config.xml for exemple, or elsewhere ?
> I can simply edit the java code of the class in the platform android, after 
> the cordova add platform, and before to build the apk.
> But i think it would be better if we can configure it in an other way.
> Or maybe, it could be done with a cordova-plugin ?
> I tried myself, but failed, to retrieve the WebSettings of the original 
> android.webkit.WebView from the CordovaWebView...
>
> Thanks for your help
>
> Stéphane

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



[PR] "Create a Minimal Reproduction Repository or Sample"

2018-11-30 Thread Jan Piotrowski
Another PR that I polished a bit and is ready for feedback and
reviews: "Create a Minimal Reproduction Repository or Sample"

PR: https://github.com/apache/cordova-contribute/pull/6
Preview: 
https://github.com/apache/cordova-contribute/blob/0a582edd0857353ff8790cbe5e6560bbcb72e7a7/create-reproduction.md

We will be able to use this to reply to GitHub issue and hopefully get
more and better reproduction repos.

-J

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



[PRs] "Deprecation and Archiving Policy"

2018-11-30 Thread Jan Piotrowski
I just finished revising my PRs regarding the deprecation and
archiving of repositories. Finishing this is needed to actually be
able to go ahead and vote on the archival of the first repositories.

1. First one is a general "Deprecation and Archiving Policy" that
would be available on our website at
https://cordova.apache.org/deprecation_policy.html:

PR: https://github.com/apache/cordova-docs/pull/878
Preview: 
https://github.com/apache/cordova-docs/blob/b8a7c650e97e3e0251464d7085b097032af16fb6/www/deprecation_policy.md#meaning-of-deprecation

2. Second are the contributor targeted instructions that would live in
https://github.com/apache/cordova-contribute. This includes the
individual steps, but also the templates for the deprecation notice to
places in README of the deprecated component:

PR: https://github.com/apache/cordova-contribute/pull/2
Preview: 
https://github.com/apache/cordova-contribute/blob/e690e4d098b3c95f997a50ec2d060b51a905993f/deprecation.md

Additionally to these two PRs, I went ahead and created
https://github.com/apache/cordova-deprecated which contains a list of
all our already deprecated components. For the plugins I added the
necessary information already. That way we can achive a repository
(making its README readonly) and still update links to alternatives
etc.

Please look over these 2 PRs I linked above, leave comments and
reviews [1]. Thanks!

Best,
Jan

[1] 
https://help.github.com/articles/reviewing-proposed-changes-in-a-pull-request/#submitting-your-review

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



Re: [dev] Cordova config.xml vs package.json?

2018-11-29 Thread Jan Piotrowski
It is important to note here to the casual observer, that of course
not _all_ configuration will be moved to package.json - only the stuff
that fits there better.
Darryl explained that above, this is mainly about moving the
"dependency" definitions right now - the rest will stay unchanged.

-J
Am Do., 29. Nov. 2018 um 00:23 Uhr schrieb Chris Brody :
>
> I was a bit too negative about the migration. I am +100 for keeping
> plugin & platform package version specs in one place, being
> package.json, and it would be nice to migrate at least some other
> project configuration info to the same place.
>
> It would be nice if we can find a way to improve the readability and
> user-friendliness in the process somehow. I find YAML a bit easier to
> read and work with but it looks like way more trouble than it would be
> worth.
>
> I hope I will get a chance to contribute to ongoing work on GitHub,
> cannot make any promise right now.
> On Mon, Nov 26, 2018 at 12:54 PM Chris Brody  wrote:
> >
> > I'm gonna downvote a complete migration to package.json for the
> > following reasons:
> > * JSON makes it harder to add items to the end of lists due to
> > trailing comma rules
> > * possible interference with npm
> > * plugins which I think are a key part of Cordova, with custom plugins
> > needed by many app developers, are not configured by package.json and
> > I think should not be configured by package.json
> >
> > Probably best to stick with XML. YAML would be nice but probably too
> > much effort
> > On Tue, Nov 20, 2018 at 1:21 PM Chris Brody  wrote:
> > >
> > > Thanks Darryl for the detailed explanation. Do you mind if we would raise 
> > > a new issue in  so that we can 
> > > track and discuss this idea in one place?
> > >
> > > (I think we don't really use cordova-discuss any more, and the existing 
> > > cordova-common PR does not look like the right place to track and 
> > > discuss.)
> > >
> > > In general I would not favor considering this idea for Cordova 9, would 
> > > be happy to give my reasons on GitHub.
> > >
> > > I think it would be best if you would be willing to raise the new issue. 
> > > I would also be happy to raise the issue if needed.
> > >
> > > On Tue, Nov 20, 2018 at 12:52 PM Darryl Pogue  wrote:
> > >>
> > >> It's not quite as simple as dropping config.xml. In all cases,
> > >> config.xml will still need to exist to provide configuration
> > >> information about the app.
> > >>
> > >> Historically, when installing platforms and plugins with `--save`,
> > >> they were added to config.xml. When running `cordova prepare`, it
> > >> would read config.xml and restore any that were listed.
> > >> Now that we're using npm for all of our fetching, it makes more sense
> > >> to store those platform/plugin dependencies in package.json.
> > >>
> > >> Relevant proposals:
> > >> https://github.com/apache/cordova-discuss/blob/master/proposals/save-restore.md
> > >> https://github.com/apache/cordova-discuss/pull/53
> > >>
> > >> Currently, Cordova will attempt to use both package.json and
> > >> config.xml, and mirror installed plugins to both locations.
> > >> Unfortunately, handling of the spec value seems to be buggy depending
> > >> on which location it reads from.
> > >>
> > >> It would be great if Cordova 9 could drop the code that mirrors
> > >> changes to config.xml and use only package.json, but nobody has really
> > >> started work on that yet. The closest is an unfinished helper class
> > >> that I was hoping to add to cordova-common to assist with package.json
> > >> changes: https://github.com/apache/cordova-common/pull/34
> > >>
> > >> I was also kinda hoping that this could all be tackled as part of the
> > >> `cordova install` proposal, but it probably makes sense to handle it
> > >> in smaller pieces.
> > >>
> > >>
> > >> On Tue, Nov 20, 2018 at 9:38 AM Chris Brody  
> > >> wrote:
> > >> >
> > >> > My understanding is that Cordova 8 is using both config.xml and
> > >> > package.json. Any plugins and platforms specified in config.xml will be
> > >> > automatically added in package.json if not already there. My 
> > >> > understanding
> > >> > is that Cordova will drop config.xml in a new release, forget if this 
> > >> > was
> > >> > planned for Cordova 9 or not.
> > >> >
> > >> > Can anyone confirm the following:
> > >> >
> > >> > Do we plan to drop config.xml support in Cordova 9? If so, any 
> > >> > pointers to
> > >> > where this was discussed and agreed?
> > >> >
> > >> > If not, do we plan to drop config.xml support in some other future 
> > >> > Cordova
> > >> > release? Any pointers to the discussion?
> > >>
> > >> -
> > >> 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...

Re: What is the status of plugreg?

2018-11-27 Thread Jan Piotrowski
Even more context:
https://cordova.apache.org/announcements/2015/04/21/plugins-release-and-move-to-npm.html
Am Di., 27. Nov. 2018 um 23:21 Uhr schrieb Jan Piotrowski
:
>
> You probably refer to the "Cordova Plugin Registry":
>
> * https://cordova.apache.org/news/2013/10/21/cordova-registry.html
> âśž https://cordova.apache.org/news/2015/09/08/cpr-readonly.html
>
> -J
>
> Am Di., 27. Nov. 2018 um 23:17 Uhr schrieb Darryl Pogue :
> >
> > plugreg was a 3rd party website displaying stats from the Cordova
> > Plugin Registry (back before we used npm)
> >
> > I don't believe it was ever officially affiliated with Apache Cordova.
> >
> > On Tue, Nov 27, 2018 at 2:13 PM Chris Brody  wrote:
> > >
> > > I think plugreg was a registry made 5-7 years ago, before PhoneGap
> > > Build was available and before Cordova was using npm. I think that
> > > plugreg is not used any more since npm gives us what we need.
> > >
> > > Can any PMC members confirm?
> > >
> > > -
> > > 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: What is the status of plugreg?

2018-11-27 Thread Jan Piotrowski
You probably refer to the "Cordova Plugin Registry":

* https://cordova.apache.org/news/2013/10/21/cordova-registry.html
âśž https://cordova.apache.org/news/2015/09/08/cpr-readonly.html

-J

Am Di., 27. Nov. 2018 um 23:17 Uhr schrieb Darryl Pogue :
>
> plugreg was a 3rd party website displaying stats from the Cordova
> Plugin Registry (back before we used npm)
>
> I don't believe it was ever officially affiliated with Apache Cordova.
>
> On Tue, Nov 27, 2018 at 2:13 PM Chris Brody  wrote:
> >
> > I think plugreg was a registry made 5-7 years ago, before PhoneGap
> > Build was available and before Cordova was using npm. I think that
> > plugreg is not used any more since npm gives us what we need.
> >
> > Can any PMC members confirm?
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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



Re: cordova-mobile-spec / Mobile Spec

2018-11-26 Thread Jan Piotrowski
After some more time with it and creating the PRs, I think this is an
appropriate description of cordova-mobile-spec:

> This `cordova-mobile-spec` repository can be used to create a Cordova app 
> that provides a set of manual tests to verify Cordova core functionality.
> It also provides access to manual and automated tests of the installed 
> plugins (via `cordova-plugin-test-framework`)

Here is the promised list of PRs (and issues):

https://github.com/apache/cordova-mobile-spec/pull/154 - Clean up and
rewrite READMEs
https://github.com/apache/cordova-mobile-spec/pull/153 - Improve
createmobilespec/createmobilespec.js
https://github.com/apache/cordova-mobile-spec/pull/152 - fix location
of key and build-extra.gradle for cordova-anroid 7.x
https://github.com/apache/cordova-mobile-spec/pull/148 - remove
deprecated platforms

The test server for Cordova Plugin File-Transfer is closely connected to this:
https://github.com/apache/cordova-labs/pull/15 - Update dependencies
and replace iconv with iconv-lite
https://github.com/apache/cordova-labs/issues/16 - Move
cordova-filetransfer branch to cordova-plugin-file-transfer repo?

Please go through and review them so I can then merge them. Thanks.

-J
Am Sa., 24. Nov. 2018 um 12:29 Uhr schrieb Jan Piotrowski
:
>
> After spending some time with it, I think I have a rough idea:
>
> `Mobile Spec` has 3 parts:
>
> 1. The main folder is a Cordova app "template" (`config.xml` and
> `www`) that includes implementations of various functionalities that
> Cordova supports (battery, events, keyboard, lazyloadjs,
> splashscreens, sql, storage, misc) that can manually be tested, some
> kind of benchmarks, and a link to the automated and manual tests
> installed plugins offer (`cdvtests/index.html`).
>
> 2. There are 4 plugin folders as well: cordova-plugin-echo,
> cordova-plugin-mobilespec-tests, cordova-plugin-thirdparty-tests and
> cordova-plugin-whitelist (which is different from the normal
> cordova-plugin-whitelist, some testing for it I guess).
>
> 3. And then there is `createmobilespec` which includes a script/CLI to
> create a Cordova app
> a) from the installed Cordova CLI, the current platforms and plugins
> (including their tests!), and the 4 local plugins (mode `--global`) or
> b) from the local checkouts (via cordova-coho) of all these (CLI,
> tools, platforms, plugins...) or
> c) with many more modes (to e.g. use plugman and /bin/create instead
> of the CLI) I didn't fully figure out or test yet.
> (When trying to run 3b, create the app with all `master` of the
> tooling, I currently get an error:
> https://github.com/apache/cordova-cli/issues/362)
>
> The end result is a folder `mobilespec` with an actual, working
> Cordova app that can be installed on devices. It can be used for some
> manual testing with the functionality offered by 1) or run the tests
> additionally provided by the plugins.
>
> Remain the following questions:
>
> How and when was this usually used?
> Was this ever used in a CI context?
> How do the benchmarks work and what do they test?
>
> I am currently working on updating the READMEs of the project with
> what I learned and will create several PRs that I will announce here
> when done.
>
> -J
> Am Fr., 23. Nov. 2018 um 19:37 Uhr schrieb Jan Piotrowski
> :
> >
> > Some historical context:
> > https://phonegap.com/blog/2009/11/04/mobile-spec-is-here/
> > (original at 
> > http://web.archive.org/web/20120428171918/http://blogs.nitobi.com/fil/2009/11/04/mobile-spec-is-here/)
> > https://www.youtube.com/watch?v=Vb1oU41mDS0
> > http://web.archive.org/web/20160304042105/http://www.feedhenry.com/extending-cordova-mobile-spec-tester-app-cloud/
> > Am Fr., 23. Nov. 2018 um 19:20 Uhr schrieb Jan Piotrowski
> > :
> > >
> > > Hey Cordova veterans,
> > >
> > > We are currently looking into improving the platform testing, release
> > > and voting process (to avoid issues like the broken plugins in
> > > cordova-android 7.1.3) in https://github.com/apache/cordova/issues/54
> > > There we stumbled over mobile-spec as another form of testing the app.
> > >
> > > Per its documentation mobile-spec...
> > >
> > > > ... is a set of automated & manual tests that test Cordova core 
> > > > functionality.
> > >
> > > Can someone share how it came to be, what exactly it does, how and
> > > where it is meant to be used? Was it ever used in a CI environment?
> > >
> > > From a search on GitHub
> > > (https://github.com/search?q=org%3Aapache+mobile-spec&type=Code) it
> > > seems to be used in some platform test scripts as well.
> > >
> > > Any documentation or guides we should be aware of?
> > >
> > > Best,
> > > Jan

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



Re: cordova-mobile-spec / Mobile Spec

2018-11-24 Thread Jan Piotrowski
After spending some time with it, I think I have a rough idea:

`Mobile Spec` has 3 parts:

1. The main folder is a Cordova app "template" (`config.xml` and
`www`) that includes implementations of various functionalities that
Cordova supports (battery, events, keyboard, lazyloadjs,
splashscreens, sql, storage, misc) that can manually be tested, some
kind of benchmarks, and a link to the automated and manual tests
installed plugins offer (`cdvtests/index.html`).

2. There are 4 plugin folders as well: cordova-plugin-echo,
cordova-plugin-mobilespec-tests, cordova-plugin-thirdparty-tests and
cordova-plugin-whitelist (which is different from the normal
cordova-plugin-whitelist, some testing for it I guess).

3. And then there is `createmobilespec` which includes a script/CLI to
create a Cordova app
a) from the installed Cordova CLI, the current platforms and plugins
(including their tests!), and the 4 local plugins (mode `--global`) or
b) from the local checkouts (via cordova-coho) of all these (CLI,
tools, platforms, plugins...) or
c) with many more modes (to e.g. use plugman and /bin/create instead
of the CLI) I didn't fully figure out or test yet.
(When trying to run 3b, create the app with all `master` of the
tooling, I currently get an error:
https://github.com/apache/cordova-cli/issues/362)

The end result is a folder `mobilespec` with an actual, working
Cordova app that can be installed on devices. It can be used for some
manual testing with the functionality offered by 1) or run the tests
additionally provided by the plugins.

Remain the following questions:

How and when was this usually used?
Was this ever used in a CI context?
How do the benchmarks work and what do they test?

I am currently working on updating the READMEs of the project with
what I learned and will create several PRs that I will announce here
when done.

-J
Am Fr., 23. Nov. 2018 um 19:37 Uhr schrieb Jan Piotrowski
:
>
> Some historical context:
> https://phonegap.com/blog/2009/11/04/mobile-spec-is-here/
> (original at 
> http://web.archive.org/web/20120428171918/http://blogs.nitobi.com/fil/2009/11/04/mobile-spec-is-here/)
> https://www.youtube.com/watch?v=Vb1oU41mDS0
> http://web.archive.org/web/20160304042105/http://www.feedhenry.com/extending-cordova-mobile-spec-tester-app-cloud/
> Am Fr., 23. Nov. 2018 um 19:20 Uhr schrieb Jan Piotrowski
> :
> >
> > Hey Cordova veterans,
> >
> > We are currently looking into improving the platform testing, release
> > and voting process (to avoid issues like the broken plugins in
> > cordova-android 7.1.3) in https://github.com/apache/cordova/issues/54
> > There we stumbled over mobile-spec as another form of testing the app.
> >
> > Per its documentation mobile-spec...
> >
> > > ... is a set of automated & manual tests that test Cordova core 
> > > functionality.
> >
> > Can someone share how it came to be, what exactly it does, how and
> > where it is meant to be used? Was it ever used in a CI environment?
> >
> > From a search on GitHub
> > (https://github.com/search?q=org%3Aapache+mobile-spec&type=Code) it
> > seems to be used in some platform test scripts as well.
> >
> > Any documentation or guides we should be aware of?
> >
> > Best,
> > Jan

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



Re: [DISCUSS] cordova-android@7.1.4 accelerated hotfix release coming

2018-11-24 Thread Jan Piotrowski
(You should have create a new thread instead of replying to this old
one for this. Please do so in the future)

I can recreate that issue when using the current mobilespec
instructions. I reported it in the CLI repository:
https://github.com/apache/cordova-cli/issues/362

But I am currently also working through the whole mobilespec project
(see the thread I created yesterday here) and will create several PRs
to fix the instructions.

If you _just_ want to have a working mobilespec project, use the
`--global` argument for `createmobilespec.js`. This uses the global
`cordova` and downloads the platforms and plugins from NPM, but it
creates a working app.

-J
Am Sa., 24. Nov. 2018 um 08:21 Uhr schrieb gandhi rajan
:
>
> Hi Chris and Jan,
>
> Recently I was working on mobilespec project for testing android platform.
> But for past two patches I m not able to create mobilespec project
> successfully which I made it work earlier after discussion with Jan on
> Slack. While trying to create mobilespec project, I get the error trace as
> mentioned in the link - https://imgur.com/a/jDHIlAB
>
> You were able to build the project with latest code without any error? Am I
> missing something? Please let me know
>
> On Fri, Nov 23, 2018 at 6:58 PM Chris Brody  wrote:
>
> > 1-2 more votes on the VOTE thread would be appreciated.
> >
> > I updated the mobilespec document as requested and recorded my
> > findings on mobilespec in https://github.com/apache/cordova/issues/54
> > On Fri, Nov 23, 2018 at 6:33 AM Jan Piotrowski 
> > wrote:
> > >
> > > Great, please also update mobilespec documentation on how to use this
> > > - that really needs some refreshing.
> > > Am Fr., 23. Nov. 2018 um 02:18 Uhr schrieb Chris Brody <
> > chris.br...@gmail.com>:
> > > >
> > > > I just built and ran the mobilespec, with quite a bit of trial and
> > > > error, will report in issue 54 when I get a chance. I was able to get
> > > > most of the "automatic" mobilespec tests to succeed, but selecting 1
> > > > plugin at a time to run the tests on. I will go ahead with the patch
> > > > release now.
> > > > On Thu, Nov 22, 2018 at 5:37 PM Jan Piotrowski 
> > wrote:
> > > > >
> > > > > I created https://github.com/apache/cordova/issues/54 for the work
> > on
> > > > > or discussion about this.
> > > > > Am Do., 22. Nov. 2018 um 23:22 Uhr schrieb julio cesar sanchez
> > > > > :
> > > > > >
> > > > > > Yeah, I agree, we shouldn’t delay because of that, but we should
> > definitely
> > > > > > figure it out before next major release
> > > > > >
> > > > > > El El jue, 22 nov 2018 a las 23:12, Jan Piotrowski <
> > piotrow...@gmail.com>
> > > > > > escribiĂł:
> > > > > >
> > > > > > > No reason to slow down the release process - anyone can do that
> > for
> > > > > > > themselves and -1 the release vote if it shows a problem.
> > > > > > > Am Do., 22. Nov. 2018 um 20:55 Uhr schrieb Chris Brody <
> > > > > > > chris.br...@gmail.com>:
> > > > > > > >
> > > > > > > > I can look into that tomorrow. It would definitely delay the
> > release,
> > > > > > > > unless someone else wants to pick this up.
> > > > > > > > On Thu, Nov 22, 2018 at 2:45 PM Darryl Pogue <
> > dvpdin...@gmail.com>
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Can we please try to figure out how to run mobilespec or
> > paramedic or
> > > > > > > > > some sort of regression test against our core plugins before
> > > > > > > > > releasing?
> > > > > > > > >
> > > > > > > > > On Thu, Nov 22, 2018 at 11:36 AM Chris Brody <
> > chris.br...@gmail.com>
> > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Does anyone have any reason to delay a
> > cordova-android@7.1.4
> > > > > > > > > > accelerated hotfix release?
> > > > > > > > > >
> > > > > > > > > > Any outstanding patches to land?
> > > > > > > > > >
> > > > > > > > > > If not, I will start the release now.
> &

Re: cordova-mobile-spec / Mobile Spec

2018-11-23 Thread Jan Piotrowski
Some historical context:
https://phonegap.com/blog/2009/11/04/mobile-spec-is-here/
(original at 
http://web.archive.org/web/20120428171918/http://blogs.nitobi.com/fil/2009/11/04/mobile-spec-is-here/)
https://www.youtube.com/watch?v=Vb1oU41mDS0
http://web.archive.org/web/20160304042105/http://www.feedhenry.com/extending-cordova-mobile-spec-tester-app-cloud/
Am Fr., 23. Nov. 2018 um 19:20 Uhr schrieb Jan Piotrowski
:
>
> Hey Cordova veterans,
>
> We are currently looking into improving the platform testing, release
> and voting process (to avoid issues like the broken plugins in
> cordova-android 7.1.3) in https://github.com/apache/cordova/issues/54
> There we stumbled over mobile-spec as another form of testing the app.
>
> Per its documentation mobile-spec...
>
> > ... is a set of automated & manual tests that test Cordova core 
> > functionality.
>
> Can someone share how it came to be, what exactly it does, how and
> where it is meant to be used? Was it ever used in a CI environment?
>
> From a search on GitHub
> (https://github.com/search?q=org%3Aapache+mobile-spec&type=Code) it
> seems to be used in some platform test scripts as well.
>
> Any documentation or guides we should be aware of?
>
> Best,
> Jan

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



cordova-mobile-spec / Mobile Spec

2018-11-23 Thread Jan Piotrowski
Hey Cordova veterans,

We are currently looking into improving the platform testing, release
and voting process (to avoid issues like the broken plugins in
cordova-android 7.1.3) in https://github.com/apache/cordova/issues/54
There we stumbled over mobile-spec as another form of testing the app.

Per its documentation mobile-spec...

> ... is a set of automated & manual tests that test Cordova core functionality.

Can someone share how it came to be, what exactly it does, how and
where it is meant to be used? Was it ever used in a CI environment?

>From a search on GitHub
(https://github.com/search?q=org%3Aapache+mobile-spec&type=Code) it
seems to be used in some platform test scripts as well.

Any documentation or guides we should be aware of?

Best,
Jan

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



Re: [VOTE] cordova-android@7.1.4 accelerated hotfix release

2018-11-23 Thread Jan Piotrowski
+1 for both

* Created and started hello world app
* Confirmed hello world app also starts with
`cordova-plugin-inappbrowser` and `cordova-plugin-local-notification`
installed
* Windows/AppVeyor CI is red for the tagged commit (because of
AppVeyor infrastructure things, see
https://github.com/apache/cordova-android/issues/579), but that
doesn't matter that much because the PR merge itself was green. Good
enough.
Am Fr., 23. Nov. 2018 um 05:55 Uhr schrieb Darryl Pogue :
>
> I vote +1 for cordova-android@7.1.4 release and +1 for the accelerated release
>
> * Confirmed sigs & hashes with `coho verify-archive`
> * Verified sha1s match tags with `coho verify-tags`
>
> -
> 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.1.4 accelerated hotfix release coming

2018-11-23 Thread Jan Piotrowski
Great, please also update mobilespec documentation on how to use this
- that really needs some refreshing.
Am Fr., 23. Nov. 2018 um 02:18 Uhr schrieb Chris Brody :
>
> I just built and ran the mobilespec, with quite a bit of trial and
> error, will report in issue 54 when I get a chance. I was able to get
> most of the "automatic" mobilespec tests to succeed, but selecting 1
> plugin at a time to run the tests on. I will go ahead with the patch
> release now.
> On Thu, Nov 22, 2018 at 5:37 PM Jan Piotrowski  wrote:
> >
> > I created https://github.com/apache/cordova/issues/54 for the work on
> > or discussion about this.
> > Am Do., 22. Nov. 2018 um 23:22 Uhr schrieb julio cesar sanchez
> > :
> > >
> > > Yeah, I agree, we shouldn’t delay because of that, but we should 
> > > definitely
> > > figure it out before next major release
> > >
> > > El El jue, 22 nov 2018 a las 23:12, Jan Piotrowski 
> > > escribiĂł:
> > >
> > > > No reason to slow down the release process - anyone can do that for
> > > > themselves and -1 the release vote if it shows a problem.
> > > > Am Do., 22. Nov. 2018 um 20:55 Uhr schrieb Chris Brody <
> > > > chris.br...@gmail.com>:
> > > > >
> > > > > I can look into that tomorrow. It would definitely delay the release,
> > > > > unless someone else wants to pick this up.
> > > > > On Thu, Nov 22, 2018 at 2:45 PM Darryl Pogue 
> > > > wrote:
> > > > > >
> > > > > > Can we please try to figure out how to run mobilespec or paramedic 
> > > > > > or
> > > > > > some sort of regression test against our core plugins before
> > > > > > releasing?
> > > > > >
> > > > > > On Thu, Nov 22, 2018 at 11:36 AM Chris Brody 
> > > > wrote:
> > > > > > >
> > > > > > > Does anyone have any reason to delay a cordova-android@7.1.4
> > > > > > > accelerated hotfix release?
> > > > > > >
> > > > > > > Any outstanding patches to land?
> > > > > > >
> > > > > > > If not, I will start the release now.
> > > > > > >
> > > > > > > -
> > > > > > > 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
> >
>
> -
> 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.1.4 accelerated hotfix release coming

2018-11-22 Thread Jan Piotrowski
I created https://github.com/apache/cordova/issues/54 for the work on
or discussion about this.
Am Do., 22. Nov. 2018 um 23:22 Uhr schrieb julio cesar sanchez
:
>
> Yeah, I agree, we shouldn’t delay because of that, but we should definitely
> figure it out before next major release
>
> El El jue, 22 nov 2018 a las 23:12, Jan Piotrowski 
> escribiĂł:
>
> > No reason to slow down the release process - anyone can do that for
> > themselves and -1 the release vote if it shows a problem.
> > Am Do., 22. Nov. 2018 um 20:55 Uhr schrieb Chris Brody <
> > chris.br...@gmail.com>:
> > >
> > > I can look into that tomorrow. It would definitely delay the release,
> > > unless someone else wants to pick this up.
> > > On Thu, Nov 22, 2018 at 2:45 PM Darryl Pogue 
> > wrote:
> > > >
> > > > Can we please try to figure out how to run mobilespec or paramedic or
> > > > some sort of regression test against our core plugins before
> > > > releasing?
> > > >
> > > > On Thu, Nov 22, 2018 at 11:36 AM Chris Brody 
> > wrote:
> > > > >
> > > > > Does anyone have any reason to delay a cordova-android@7.1.4
> > > > > accelerated hotfix release?
> > > > >
> > > > > Any outstanding patches to land?
> > > > >
> > > > > If not, I will start the release now.
> > > > >
> > > > > -
> > > > > 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] cordova-android@7.1.4 accelerated hotfix release coming

2018-11-22 Thread Jan Piotrowski
No reason to slow down the release process - anyone can do that for
themselves and -1 the release vote if it shows a problem.
Am Do., 22. Nov. 2018 um 20:55 Uhr schrieb Chris Brody :
>
> I can look into that tomorrow. It would definitely delay the release,
> unless someone else wants to pick this up.
> On Thu, Nov 22, 2018 at 2:45 PM Darryl Pogue  wrote:
> >
> > Can we please try to figure out how to run mobilespec or paramedic or
> > some sort of regression test against our core plugins before
> > releasing?
> >
> > On Thu, Nov 22, 2018 at 11:36 AM Chris Brody  wrote:
> > >
> > > Does anyone have any reason to delay a cordova-android@7.1.4
> > > accelerated hotfix release?
> > >
> > > Any outstanding patches to land?
> > >
> > > If not, I will start the release now.
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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



Re: cordova-android@7.1.3 patch release?

2018-11-15 Thread Jan Piotrowski
#555 links to PRs and issues randomly - I have no idea what is going on there.
Please update the PR description to link to the Pull Requests whose
changes are included in this PR (and optionally the issue those are
solving).

-J
Am Do., 15. Nov. 2018 um 14:00 Uhr schrieb Chris Brody :
>
> Changes are proposed and discussed in:
> https://github.com/apache/cordova-android/pull/555
>
> Waiting for final approval of
> https://github.com/apache/cordova-android/pull/561 which will be
> included by cherry-pick.
>
> Does anyone have any reason to delay a cordova-android@7.1.3 patch release?
>
> Any outstanding patches to land?
>
> If not, I will start the release tomorrow.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>

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



Re: Facing issue in testing release process of Cordova platforms

2018-11-01 Thread Jan Piotrowski
The documented command actually is just
"./cordova-mobile-spec/createmobilespec/createmobilespec.js --android
--forceplugins", without the "node" in front of it. But I am not sure
if this is correct or just a bug in the documentation.

Please reply with the full command you are executing and the full
output you are getting.

> I did install cordova-js and cordova-lib modules ...

Where did you run which command exactly to try to fix this?

Best,
Jan

PS: Yep, mobilespec is heavily underdocumented as most of the testing stuff.


Am Do., 1. Nov. 2018 um 18:10 Uhr schrieb gandhi rajan
:
>
> Hi Jan,
>
> Thanks for your response. I did checkout  all repos using the coho command
> - "coho repo-update -g -r all"
>
> While trying to do plugin tests as mentioned in
> https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md#1-plugin-tests-with-cordova-mobile-spec-project,
> I executed the following command in my windows system:
>
> "node ./cordova-mobile-spec/createmobilespec/createmobilespec.js --android
> --forceplugins"
>
> I got the following error while executing the above command:
>
> "Error: Module cordova-js is not installed at all (direct or npm-linked) in
> cordova-lib"
>
> I did install cordova-js and cordova-lib modules but couldn't get away from
> this error. Jesse did pointed out that we dont do this test until we make
> some breaking changes in platform but just curious to resolve this issue as
> we may encounter this error anytime in future.
>
> Let me know your thoughts.
>
> On Wed, Oct 31, 2018 at 11:07 PM Jan Piotrowski 
> wrote:
>
> > Gandhi, what exactly did you do until now? Do you have a checkout of
> > all the Cordova repos created with coho?
> >
> > Please reply with the exact command you are running and error/output
> > you are getting.
> >
> > J
> > Am Sa., 27. Okt. 2018 um 11:02 Uhr schrieb gandhi rajan
> > :
> > >
> > > Hi Raphinesse, Thanks for the Jasmine 3 update. I m now able to build and
> > > install cordova-js module.
> > >
> > > @jesse, I tried the steps you mentioned to test platform and it works.
> > But
> > > I m still not able to create and run mobile-spec project.While running
> > the
> > > following command - "node
> > > cordova-mobile-spec\createmobilespec\createmobilespec.js --android
> > > --forceplugins", I get the following error - Error: Module cordova-js is
> > > not installed at all (direct or npm-linked) in cordova-lib
> > >
> > > Any thoughts on this?
> > >
> > > On Thu, Oct 25, 2018 at 11:43 PM gandhi rajan 
> > > wrote:
> > >
> > > > Thanks a lot for the response Jesse and Raphinesse. Will try out the
> > > > suggested steps and check out the merge as well. Will get back with
> > further
> > > > updates if I m stuck.
> > > >
> > > > On Thursday, October 25, 2018,  wrote:
> > > >
> > > >> I already updated cordova-js to use more modern tooling some time ago
> > in
> > > >> https://github.com/apache/cordova-js/pull/176.  I just had not gotten
> > > >> around to merging it yet. I did so just now.
> > > >>
> > > >> Jesse  schrieb am Do., 25. Okt. 2018, 10:19:
> > > >>
> > > >> > Hi Gandhi,
> > > >> >
> > > >> > There is an issue with this repo in that cordova-js uses a
> > jasmine-node
> > > >> > version that depends on a non-secure version of growl.  This is not
> > a
> > > >> > trivial fix as moving to the recommended jasmine-node@2.0.1 is a
> > > >> breaking
> > > >> > change.
> > > >> > I am not completely of the mind that updating is the right approach
> > > >> here,
> > > >> > as I think in many ways the cordova-js project is outdated, and the
> > > >> whole
> > > >> > process of generating platform specific cordova.js files needs to be
> > > >> > rethought.
> > > >> >
> > > >> > Personally, this does not block me ... I do the following:
> > > >> > ⚡ npm i
> > > >> > audited 684 packages in 2.085s
> > > >> > found 1 critical severity vulnerability
> > > >> >   run `npm audit fix` to fix them, or `npm audit` for details
> > > >> >
> > > >> > ⚡ npx grunt
> > > >> > ... succeeds
> > > >> >
> &g

Re: Facing issue in testing release process of Cordova platforms

2018-10-31 Thread Jan Piotrowski
Gandhi, what exactly did you do until now? Do you have a checkout of
all the Cordova repos created with coho?

Please reply with the exact command you are running and error/output
you are getting.

J
Am Sa., 27. Okt. 2018 um 11:02 Uhr schrieb gandhi rajan
:
>
> Hi Raphinesse, Thanks for the Jasmine 3 update. I m now able to build and
> install cordova-js module.
>
> @jesse, I tried the steps you mentioned to test platform and it works. But
> I m still not able to create and run mobile-spec project.While running the
> following command - "node
> cordova-mobile-spec\createmobilespec\createmobilespec.js --android
> --forceplugins", I get the following error - Error: Module cordova-js is
> not installed at all (direct or npm-linked) in cordova-lib
>
> Any thoughts on this?
>
> On Thu, Oct 25, 2018 at 11:43 PM gandhi rajan 
> wrote:
>
> > Thanks a lot for the response Jesse and Raphinesse. Will try out the
> > suggested steps and check out the merge as well. Will get back with further
> > updates if I m stuck.
> >
> > On Thursday, October 25, 2018,  wrote:
> >
> >> I already updated cordova-js to use more modern tooling some time ago in
> >> https://github.com/apache/cordova-js/pull/176.  I just had not gotten
> >> around to merging it yet. I did so just now.
> >>
> >> Jesse  schrieb am Do., 25. Okt. 2018, 10:19:
> >>
> >> > Hi Gandhi,
> >> >
> >> > There is an issue with this repo in that cordova-js uses a jasmine-node
> >> > version that depends on a non-secure version of growl.  This is not a
> >> > trivial fix as moving to the recommended jasmine-node@2.0.1 is a
> >> breaking
> >> > change.
> >> > I am not completely of the mind that updating is the right approach
> >> here,
> >> > as I think in many ways the cordova-js project is outdated, and the
> >> whole
> >> > process of generating platform specific cordova.js files needs to be
> >> > rethought.
> >> >
> >> > Personally, this does not block me ... I do the following:
> >> > ⚡ npm i
> >> > audited 684 packages in 2.085s
> >> > found 1 critical severity vulnerability
> >> >   run `npm audit fix` to fix them, or `npm audit` for details
> >> >
> >> > ⚡ npx grunt
> >> > ... succeeds
> >> >
> >> > ⚡ npx grunt compile:windows
> >> > Running "compile:windows" (compile) task
> >> > generated cordova.windows.js @ 243e7aac8cee0108927df0253118e36857ab9fc7
> >> in
> >> > 5ms
> >> > Done.
> >> >
> >> > The typical way a platform is released is to use cordova-coho.
> >> > ex. `coho prepare-platform-release-branch -r cordova-android --version
> >> > 9.9.9`
> >> > This takes care of all the tagging, building/copying of cordova.js to
> >> the
> >> > correct platform folder.
> >> >
> >> > About the mobile-spec workflow, I have not done this is a long time,
> >> this
> >> > was more important when we were breaking things a lot.  One expectation
> >> of
> >> > the tooling that may not be explicitly listed is that all repos are
> >> > expected to be cloned as peers.  cordova-coho has commands that can help
> >> > manage the multitude of repos for you.
> >> >
> >> > Not sure if this helps you move forward, I am happy to dig into this
> >> more
> >> > with you.
> >> >
> >> > Cheers,
> >> >   Jesse
> >> >
> >> > @purplecabbage
> >> > risingj.com
> >> >
> >> >
> >> > On Tue, Oct 23, 2018 at 10:22 PM gandhi rajan 
> >> > wrote:
> >> >
> >> > > Hi All,
> >> > >
> >> > > I was trying to understand the release process for Cordova platforms
> >> as
> >> > > mentioned in the following link -
> >> > >
> >> > >
> >> >
> >> https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md
> >> > > .
> >> > >
> >> > > While following the steps mentioned to test plugins with
> >> > > cordova-mobile-spec project, I got an error stating cordova-js module
> >> is
> >> > > not installed. When I tried to install cordova-js, the installation
> >> fails
> >> > > stating one critical severity vulnerability.On running npm audit on
> >> > > cordova-js, it states that the critical vulnerability is related to
> >> growl
> >> > > version.
> >> > >
> >> > > Can someone let me know whether I m missing some steps which is
> >> causing
> >> > > this issue or it's a vulnerability that needs to be fixed as I m not
> >> able
> >> > > to proceed with cordova-js module installation?
> >> > >
> >> > > Any help is really appreciated. Thanks in advance.
> >> > >
> >> > >
> >> > > --
> >> > > Regards,
> >> > > Gandhi
> >> > >
> >> > > "The best way to find urself is to lose urself in the service of
> >> others
> >> > > !!!"
> >> > >
> >> >
> >>
> >
> >
> > --
> > Regards,
> > Gandhi
> >
> > "The best way to find urself is to lose urself in the service of others
> > !!!"
> >
> >
>
> --
> Regards,
> Gandhi
>
> "The best way to find urself is to lose urself in the service of others !!!"

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



Re: plugins release?

2018-10-31 Thread Jan Piotrowski
Julio, I would be happy to pair with you on some plugin releases.

As you already noticed, the release processes via coho need some
serious work now that we are on GitHub issues instead of JIRA, so we
have some additional work ahead of us.

First step would be to identify which plugin to start with.
(I suggest selecting just 1 and seeing that through, then continue
with more if/when we are successful).

@Oliver: What you wrote mainly applies to the platforms - the plugin
release process should be independent from that. But we will keep that
in mind of course.

J

Am Di., 16. Okt. 2018 um 13:34 Uhr schrieb Oliver Salzburg
:
>
> I believe the issue with the pending releases is not that nobody is
> performing the release task. There are still implementation details
> being worked on if I'm not mistaken.
>
> The next release will supposedly introduce several major breaking
> changes, which have to be prepared for thoroughly.
>
> On 2018-10-13 22:02, julio cesar sanchez wrote:
> > Today I was checking github issues and noticed that a lot of them were
> > supposedly fixed already, but people are reporting them again as we have
> > not done a release since April and they are using the latest release and
> > not master.
> >
> > So, is anybody willing to do a release? If not I can try, but last time I
> > tried I wasn't able to finish it because of some problem with coho.
> >
> > Also, related to coho, it supposedly creates a JIRA issue, but that's not
> > possible anymore, so should we manually create a release issue per plugin?
> > Or patch coho to automatically create them? (if possible).
> > How are you doing it since we switched to github issues? (cc Chris as I
> > think you did most/all releases since then)
> >
>
>
> -
> 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: [VOTE] cordova-lib@8.1.1 tools patch release

2018-10-03 Thread Jan Piotrowski
I vote +1:

- Ran `coho verify-tags -g` with the tag string from above
- Confirmed sigs & hashes with `coho verify-archive`
- Checked that the changes in the 8.1.x branch should do what the
"release issue" and changelog says
- Checked out 8.1.x branch and successfully ran `npm t` (and observed
1 failure from a flaky-on-Windows test)
- Checked that CI is green
- Ran `npm install` on the extracted package, observed `xcode` being installed
Am Mo., 1. Okt. 2018 um 20:08 Uhr schrieb Chris Brody :
>
> Please review and vote on this tools patch release by replying to this
> email (and keep discussion on the DISCUSS thread)
>
> Release issue: https://github.com/apache/cordova-lib/issues/706
>
> Distribution files have been published to dist/dev:
> https://dist.apache.org/repos/dist/dev/cordova/GH-706/
>
> The packages were published from their corresponding git tags:
>
> cordova-lib: 8.1.1 (54858f8892)
>
> Upon a successful vote I will upload the archives to dist/, publish
> them to npm, and post the corresponding blog post.
>
> Voting guidelines:
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
>
> Voting will go on for a minimum of 48 hours.
>
> I vote +1:
> * Ran coho audit-license-headers over the relevant repos
> * Ran coho check-license to ensure all dependencies and
> subdependencies have Apache-compatible licenses
> * Ensured continuous build was green when repos were tagged
>
> -
> 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



83 Plugin Pull Requests are ready for review!

2018-10-03 Thread Jan Piotrowski
Hi interested people.

I spent the last few days unblocking pull requests for our plugin
repositories. This meant fixing our test configuration, fixing some
specific problems of our test infrastructure and in general making
sure that PRs with failing tests were fixed and rerun.

The result: 83 pull requests for plugins are ready for review!

The simplest way to get to them are these two links:
https://github.com/orgs/apache/projects/9#column-3410961
https://github.com/orgs/apache/projects/10#column-3412110

All the pull requests in these two "Ready for Review" columns have no
test failures, no conflicts and are tagged for type and platform. Just
go in, open a few in new tabs and go through them, reading,
understanding, asking questions, clarifying both the problem and the
solution, testing, improving.

When you understood, tested and confirmed a PR please leave an
"Approve" review on the PR (and a comment if you want).

Best,
Jan

PS: If you rather want to something to debug, check out these failing
tests for cordova-plugin-file on Safari:
https://github.com/apache/cordova-plugin-file/issues/257

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



  1   2   3   >