Introduction & Request to review

Hi everyone! My name is Raphael. I'm a Software Developer with some years of professional experience. I do mostly Frontend/JavaScript including build/tooling related Node.js stuff. Sometimes I work on Cordova Apps including Android plugin development. Recently I started contributing small fixes

Re: [DISCUSS] cordova-common release

+1 Release early, release often  Darryl Pogue schrieb am Mi., 30. Mai 2018, 09:20: > Hey folks, > > There have been a number of commits[1] to cordova-common since the previous > release, primarily related to bringing outdated dependencies up to date and > tackling a backlog of bugfix pull

Re: Cordova-Android/iOS/macOS/Windows/browser patch release

Subject and mail say patch release julio cesar sanchez schrieb am Mi., 20. Juni 2018, 18:37: > Sorry, I thought you wanted to do a patch release, but I've seen you want > to do a major release, at least on Android. > In that case, there are a few PRs that we could review before doing a major >

Re: Cordova-Android/iOS/macOS/Windows/browser patch release

There are a couple of fixes on master that I would like to see in the next patch release. Will send you the SHAs to cherry-pick later Chris Brody schrieb am Mi., 20. Juni 2018, 18:48: > On Wed, Jun 20, 2018 at 12:42 PM wrote: > > > > Subject and mail say patch release > > Correct > > > julio

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

> > For Cordova tooling I expect no one outside of the developers to > really know what happens where - but if I see it correctly we almost > don't have any tooling JIRA issues as well, right? > There's plenty tooling related JIRA issues. And rightly so. IMHO, joining all tooling packages in a

Re: [DISCUSS] cordova-fetch patch release (tools)

Yes, makes perfect sense. We do need to ensure that we use the exact same cordova-common version everywhere. Thanks for the clarification. Chris Brody schrieb am Mo., 30. Juli 2018, 13:24: > I would like to make cordova-fetch patch release before dependant > cordova-lib patch release for a

Re: Time to mark major Cordova release & remove committed node_modules?

+1 Chris Brody schrieb am Di., 31. Juli 2018, 21:23: > Exactly, thanks for the clarification. > On Tue, Jul 31, 2018 at 3:19 PM Darryl Pogue wrote: > > > > +1 > > > > Just to be clear, we're proposing to bump to the next major -dev > > version, not actually making any major version releases

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

There is much I don't like about JIRA and in general I prefer GitHub issues. However, there's issues that did came up during previous discussions of this topic, and that have no proper solution that I know of - How do people know in which of the numerous Cordova repos to create their issues

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

Yes, we should definitely commit package-lock.json. Gives reliable builds and immutable releases. Conflicts during merges are common and a bit annoying, but easily resolved if you know how. There even is a git merge hook for that [1] (more info on this blog post [2]) [1]:

Re: [DISCUSS] cordova-fetch patch release (tools)

What is supposed to go into this release? As I already mentioned in https://issues.apache.org/jira/browse/CB-14145#comment-16522279 there were no audit issues in cordova-fetch last time I checked. Has this changed? Chris Brody schrieb am Mo., 30. Juli 2018, 06:41: > Does anyone have any reason

[DISCUSS] [Github Issues] Support questions in GitHub issues

Jan proposed a support label for issues more than once. That fit me thinking. Do we really want to allow support questions like this one [1] in the issues? I'm definitely against it. I think we should make that clear in the issue template and direct people to slack or stackoverflow. We might

Re: [DISCUSS] Delete apache/cordova-fauxton-server repository?

+1 Chris Brody schrieb am Mo., 6. Aug. 2018, 16:38: > +1 > On Mon, Aug 6, 2018 at 10:37 AM julio cesar sanchez > wrote: > > > > +1 > > > > El lun., 6 ago. 2018 a las 16:36, Jan Piotrowski ( >) > > escribió: > > > > > During enabling of issues and removing of "Mirror of ..." on our > > > Github

Re: Reviving Face-to-Face video meetings?

I wouldn't have objected to the live stream, but I must say I feel a bit more comfortable with the private meeting. Darryl Pogue schrieb am Mi., 15. Aug. 2018, 10:02: > I was hoping to use Hangouts on Air, because then it's also available > for viewing on YouTube, but apparently that doesn't

Re: Dealing with deprecated repos

I suggest archiving them all and deal with any issues as they appear. After all, repos can be unarchived if necessary. Chris Brody schrieb am Di., 7. Aug. 2018, 17:16: > Continuation of discussion from > >

Re: Reviving Face-to-Face video meetings?

> > let's try to have a date picked by this coming Friday (August 10th). > What's the deadline? 2018-08-10T24:00Z? > *** TIMES ARE IN UTC. PLEASE CHECK CONVERSION TO YOUR LOCAL TIME > BEFORE REPLYING. *** > Doodle explicitly tells me that times are displayed in the Europe/Berlin time zone.

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

I was under the impression that JIRA was already locked down for everyone but PMC members. But yesterday I received a comment on an old JIRA issue. Under these circumstances, I see the benefits of bulk-closing all JIRA issues. Nevertheless, I would really like to 1. have a two way link

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

Labels that I would like to have: - something to show that you are open to suggestions or want to work out how something is supposed to work. Could be "discussion" - A "Work in Progress" label I would have tried to just write a script that creates the labels via GH API. But do we have the

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

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

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

I wanted to use GitHub's GraphQL to gather some insights about cordova repos. I could not access some organization level information that I could see over the web, without requesting organization (apache) wide privileges for GraphQL. So it's not always that easy. Shazron schrieb am Do., 23.

Re: What to do with cordova-discuss?

t, I > > suggest simply using that for any design discussions. > > > > Am Do., 23. Aug. 2018 um 10:59 Uhr schrieb Jan Piotrowski < > > piotrow...@gmail.com>: > > > > > Issues can be moved e.g. with https://github-issue-mover.appspot.com/. > > >

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

I'm against migrating everything. I would just leave them in JIRA as is and resolve them when resolved. Regarding the "dangling" issues: If we re-file issues in GitHub, we would have to make sure that the corresponding issue in JIRA is properly marked as obsolete. In other words, I as a

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

Thanks for doing this! I'm not sure about the bulk closing. Last time I checked, at least for our tooling even very old issues were often still valid and provided some valuable insight for me. I'd leave them. If we want to close them, They should definitely get some label that makes them easily

Re: What to do with cordova-discuss?

com>: > Issues can be moved e.g. with https://github-issue-mover.appspot.com/. > As the issues were a thing of keeping track of stuff, I think > @raphinesse and @brodybits who created most of those issue should take > care of moving their issues to the appropriate repo or close the

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

I thought JIRA was locked anyway. So only PMC Members can make changes. If we just leave them as is, I can simply resolve an issue I fix in JIRA and all is obvious. If we ask people to reopen in GitHub, we will have a dangling seemingly unresolved duplicate in JIRA, so JIRA becomes less useful

Re: Reviving Face-to-Face video meetings?

Definitely! Chris Brody schrieb am Di., 17. Juli 2018, 20:30: > +1, would be really nice! > On Tue, Jul 17, 2018 at 2:19 PM Darryl Pogue wrote: > > > > Hey folks, > > > > In the days of old, the Cordova project tried to have semi-regular > > video conference meetings on Hangouts for

Re: https redirect needed

Depending on how the site is deployed, you might need https://stackoverflow.com/a/37006232/380229 Full disclosure: that's an answer by me. Shazron schrieb am Mo., 16. Juli 2018, 07:50: > How: > https://stackoverflow.com/a/13376283 > > Where: >

Re: GitHub Project Board: Pull Requests

Thanks again, Jan. Am Mi., 5. Sep. 2018 um 16:44 Uhr schrieb Jan Piotrowski < piotrow...@gmail.com>: > > I'd rather link cordova-create than cordova-js since the latter is not > > really tooling (it's kind of an outlier). > > Ok, changed. Makes sense. > > > But what's the difference between

Re: GitHub Project Board: Pull Requests

Thanks for creating this Jan! I'd rather link cordova-create than cordova-js since the latter is not really tooling (it's kind of an outlier). But what's the difference between linked and unlinked repos anyway? Cheers, Raphael Am Mi., 5. Sep. 2018 um 12:39 Uhr schrieb Jan Piotrowski <

Breaking changes in cordova-create

Hi! I proposed quite a few breaking changes to cordova-create some time ago. Unfortunately I have received very little feedback up until now. I would appreciate to hear what you think of my plans. Since I would like to get started on landing the changes I already have for most of my proposals, I

Re: [VOTE] cordova-cli@8.1.1 tools hotfix release

I vote +1: * Installed archive from dist/dev and successfully ran some routine tasks * Successfully ran some tasks using Node.js 4 * Checked that the telemetry prompt was working correctly Thanks for taking care of this Chris! Am Do., 27. Sep. 2018 um 13:06 Uhr schrieb Chris Brody <

Re: [VOTE] cordova-cli@8.1.2 patch release

I vote +1: - Successfully installed archive from dist/dev - Successfully ran some routine tasks including `cordova platform ios` Am Fr., 5. Okt. 2018 um 22:23 Uhr schrieb Oliver Salzburg < oliver.salzb...@gmail.com>: > I vote +1 > > - Confirmed sigs & hashes with `coho verify-archive` [1] > -

Re: Facing issue in testing release process of Cordova platforms

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

Re: [DISCUSS] Cordova 8.1.2 patch release updates coming

The subject in the vote mail says cordova-cli when the vote is actually about cordova-lib Chris Brody schrieb am Sa., 29. Sep. 2018, 00:06: > Does anyone have any reason to delay a tools release for > cordova-lib@8.1.x and cordova-cli@8.1.x? > > Any outstanding patches to land? > > If not, I

Re: GitHub Project Board: Pull Requests

Looks very nice. Great work Jan! Two questions: - What's the difference between: "Waiting for Review" and "Pending Approval"? - Do we need to distinguish "Blocked: Tests failing" and "Blocked: Conflict"? Cheers, Raphael Am Mo., 3. Sep. 2018 um 14:43 Uhr schrieb Jan Piotrowski <

Re: [VOTE] cordova-cli@8.1.0 tools release (minor patch release)

I vote +1: * Installed archive from dist/dev and successfully ran some routine tasks Am Mo., 24. Sep. 2018 um 23:23 Uhr schrieb Chris Brody < chris.br...@gmail.com>: > Please review and vote on this Cordova CLI minor Tools Release by > replying to this email (and keep discussion on the DISCUSS

Re: [dev] Introduce ES6 classes or not?

+1 for using modern JS wherever applicable. Am Fr., 30. Nov. 2018, 06:55 hat Darryl Pogue geschrieben: > I both agree and disagree with your points :P > > To your first point, yes ES6 classes are just syntactic sugar around > prototypes, but that sugar exists for a reason and it's extremely >

Re: [DISCUSS] Update dependencies for nightly builds in master

Yeah, I mean that's what we do with the nightlies already. I agree that it would be great to be notified of integration problems ASAP. But to achieve that, we should test the nightlies produced during the nightly build. Am Mi., 12. Sep. 2018 um 22:27 Uhr schrieb Oliver Salzburg <

Re: [DISCUSS] Update dependencies for nightly builds in master

Am Mi., 12. Sep. 2018 um 21:36 Uhr schrieb Jan Piotrowski < piotrow...@gmail.com>: > This uses specific nightlies the developer has to select manually, right? > I would say it would have to, since nightly alone would be an unstable moving target that would regularly break our CI tests. > How

Re: [DISCUSS] Update dependencies for nightly builds in master

Am Mi., 12. Sep. 2018 um 22:01 Uhr schrieb Chris Brody < chris.br...@gmail.com>: > On Wed, Sep 12, 2018 at 3:48 PM wrote: > > > > Am Mi., 12. Sep. 2018 um 21:36 Uhr schrieb Jan Piotrowski < > > piotrow...@gmail.com>: > > > > > This uses specific nightlies the developer has to select manually, >

Re: [DISCUSS] Update dependencies for nightly builds in master

I agree that this kind of situation should be addressed by a proper release of the dependency. If it's a breaking change, so be it. I don't mind if we have cordova-common 23.5.7 in a year from now. Am Mi., 12. Sep. 2018 um 22:44 Uhr schrieb Oliver Salzburg < oliver.salzb...@gmail.com>: > On

Re: [DISCUSS] Update dependencies for nightly builds in master

> I think, if anything, what is needed is an overall test of all the pieces > > together, but I don't think this means modifying every package.json of > > every module every night. > > > > That is exactly what my proposal aims to accomplish. > I agree that we should test all the pieces together

Re: Status of Next Major

I'm open to having an extended discussion about that. Although we should probably do that in the appropriate thread: https://lists.apache.org/thread.html/7f92561d382f143aaf49e083bbe215dcf95a3f4d8b6e3cbb6089a5f3@%3Cdev.cordova.apache.org%3E Am Di., 11. Sep. 2018 um 13:14 Uhr schrieb Oliver

Re: Status of Next Major

To follow up on my last message: To track release-blocking tasks in the different repos, we could use issues (example for cordova-osx [1]), repo-local boards or even milestones. Any opinions? [1]: https://github.com/apache/cordova-osx/issues/58 Am Mi., 12. Sep. 2018 um 12:59 Uhr schrieb : >

Re: Cordova 8.1.0 (minor release) proposal

6. Use manually edited npm-shrinkwrap.json to force a more recent version of `inquirer` ourselves. Little work, no audit warnings for the users. I could do that when the branch is ready. However, we should test the whole thing with a alpha suffix or something like that first. Am Fr., 14. Sep.

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

> - It does speed up installation of dependencies in > conjunction > > > with `npm > > > > > > ci` by skipping the entire dependency resolution and using > the > > > versions > > > > > > from the lock file. > > > > > > - It

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

; > > > > > > > With that cleared up, my stance on committing package-lock.json is as > > > > follows: > > > > > > > > - Faster CI installations and faster/easier usage of `npm audit` > are > > > > purely convenience features f

Re: Cordova 8.1.0 (minor release) proposal

I'd really like to try #6. If that does not work as expected, we can still go with #2. Jan Piotrowski schrieb am Fr., 14. Sep. 2018, 21:47: > #2 sounds absolutely fine to me as this dependency is in cordova-cli > which is only used on developer machines, not included in any deployed > packages.

Re: Cordova 8.1.0 (minor release) proposal

The only minor doubt I'd have is about the insight update: as I've mentioned in the corresponding PR, it will cause _all_ users to be pompted again about their telemetry preference. I've thought that to be OK for a major release. Might be a bit strange in a minor though. Just wanted to let you

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

]: https://github.com/raphinesse/cordova-common/pull/1#issuecomment-420950433 [3]: https://docs.npmjs.com/files/package-locks [4]: https://docs.npmjs.com/files/package-lock.json [5]: https://docs.npmjs.com/files/shrinkwrap.json [6]: https://docs.npmjs.com/getting-started/running-a-security-audit

Re: Cordova 8.1.0 (minor release) proposal

Am Fr., 14. Sep. 2018 um 14:15 Uhr schrieb Chris Brody < chris.br...@gmail.com>: > Thanks Raphael for the reminder about insight, which I overlooked. I > personally do not like the idea of an extra reminder message before the > next major release. I would like to consider this over the weekend >

Re: Status of Next Major

What do you mean by "all packages"? These reports were for cordova-osx only. However, I agree that the major of cordova-osx (and any other package) should include a dependency update. That is also a part of our release docs [1] [1]:

Re: Status of Next Major

Hey Bryan, thanks for following up on the release planning. As some of you may have noticed, yesterday (in my time zone) we completed quite a few chores that needed to be done for the next major release. From my perspective there's nothing that keeps us from starting to release. Sure, there's

Re: [DISCUSS] cordova-lib minor tools release - 8.1.0

Hey Chris! Could you please include the changes from https://github.com/apache/cordova-lib/pull/688 in the patch? They have already been approved by Jan and I think we should release it as an intermediate solution until https://github.com/apache/cordova-common/pull/50 lands. Thanks in Advance,

Re: [DISCUSS] When to do npm shrinkwrap?

s is vital for our development workflow and I have no > > >>>> experience with > > >>>>>>> package-lock.json in projects where a lot of linking is > > >> necessary. > > >>>>>>> Finally, I think we might need to re-evaluate

Re: [DISCUSS] cordova-lib minor tools release - 8.1.0

Great, thanks! Am Mo., 17. Sep. 2018 um 13:56 Uhr schrieb Chris Brody < chris.br...@gmail.com>: > Thanks Raphael. I will likely add this information to the GitHub > entries for the sake of extra clarification. > On Mon, Sep 17, 2018 at 7:39 AM wrote: > > > > I thought it was already clear from

Re: [DISCUSS] cordova-lib minor tools release - 8.1.0

I thought it was already clear from the discussion in cordova-lib#688. The gist is: - cordova-lib#688 is a hotfix of logic that should never have been where it is in the first place (from a design point of view) - cordova-common#50 fixes the underlying problem for all users of

Re: [VOTE] cordova-fetch@1.3.1 patch release

I vote +1: * Ran cordova-lib tests using cordova-fetch from the release archive Am Di., 18. Sep. 2018 um 02:18 Uhr schrieb Chris Brody < chris.br...@gmail.com>: > Please review and vote on this cordova-fetch@1.3.1 tools patch release > by replying to this email (and keep discussion on the

Re: [PR] Checking Android Build-Tools Versions

I left a review, but I would like a second opinion, preferably from someone more active in cordova-android. Am Di., 2. Apr. 2019 um 15:33 Uhr schrieb Ramazan Vapurcu : > Hi, > > Is there anyone wants to review my PR which is about to Android SDK > Build-Tools? >

Re: [VOTE] cordova-lib@9.0.1 Release

I vote +1: * CI passed for tag Am Mo., 1. Apr. 2019 um 07:42 Uhr schrieb Darryl Pogue : > Please review and vote on this cordova-lib release by replying to this > email (and keep discussion on the DISCUSS thread) > > Artifacts have been published to dist/dev: >

Re: [DISCUSS] Node 6.x & 8.x Deprecation & Node 12.x Support

Sounds reasonable and well thought out to me. Bryan Ellis schrieb am Mi., 10. Apr. 2019, 09:42: > I would like to start the discussion around Cordova's planning for > deprecating Node 6.x and Node 8.x as well as starting to support Node 12.x. > > Since Node 6.x is being deprecated by the end of

Re: [VOTE] Cordova-Plugman 3.0.1 Release

I vote +1: * Passed `npm audit` * Passed `npm test` Am Do., 11. Apr. 2019 um 14:25 Uhr schrieb Bryan Ellis : > Please review and vote on this Cordova Plugman Release v3.0.1 > by replying to this email (and keep discussion on the DISCUSS thread) > > The archive has been published to dist/dev: >

Re: Plugins and Node.js versions

 Jan Piotrowski schrieb am Fr., 17. Mai 2019, 12:14: > 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 : > >

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

+1 Reviewed changes since last version Am Mi., 12. Juni 2019 um 11:19 Uhr schrieb Jan Piotrowski < piotrow...@gmail.com>: > +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 < >

Re: Plugins and Node.js versions

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

[DISCUSS] Remove all documentation translations

Doc translations are not being actively maintained and are thus outdated. Furthermore, at least some of the existing translations seem to be really bad too. Consequently I propose to remove all translations from the docs (cordova-docs as well as any other repos). I checked the guide entry page

Re: [DISCUSS] non-global Cordova installs

Thanks for that structured write-up, Oliver. You saved me from writing all of that myself. +100 on all those points Oliver Salzburg schrieb am Fr., 10. Mai 2019, 11:01: > I don't see how third-party tools like nvm or nvm-windows play a role in > this. If those tools have defects, so be it, but

Re: [DISCUSS] Remove all documentation translations

+1 to what Jan said Jan Piotrowski schrieb am Do., 16. Mai 2019, 10:54: > 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

Re: UI landing page cordova

Thank you for reporting this. I can't see the screenshot you attached though. Please open an issue at https://github.com/apache/cordova-docs instead. Thanks in advance, Raphael Thái Lý Quang schrieb am So., 21. Apr. 2019, 09:41: > Hi team, I found 1 issue UI was broken down > [image:

Re: What is the relationship between package.json and config.xml?

You should definitely have both of these files under version control. package.json is the primary source for specifying dependencies in Cordova 9. Specifying them in config.xml will probably be not supported anymore in Cordova 10. All other application configuration will remain in config.xml.

Re: [DISCUSS] Node 6.x & 8.x Deprecation & Node 12.x Support

I recently thought about whether we should be having a release candidate for the next major versions. At least for platforms and the CLIs I think that would make sense. Am Mi., 10. Apr. 2019 um 16:24 Uhr schrieb Darryl Pogue : > +1 > > One suggestion: If (and this is a big if) we're able to get

Re: [VOTE] Cordova-ESLint 2.0.0 Release

I vote +1: * Ensured CI was green at tag * Successfully installed and applied the config from the tar ball to cordova-browser Am Mo., 11. Nov. 2019 um 10:44 Uhr schrieb Bryan Ellis : > Please review and vote on this Cordova ESLint Major Release v2.0.0 > by replying to this email (and keep

Re: [VOTE] Cordova-ESLint 1.0.0 Release

I vote +1: * `npm test` passes (Lints itself) * I manually tested it on cordova-create Am Do., 7. Nov. 2019 um 12:07 Uhr schrieb Bryan Ellis : > Please review and vote on this Cordova ESLint Major Release v1.0.0 > by replying to this email (and keep discussion on the DISCUSS thread) > > The

Re: [GitHub] [cordova-eslint] raphinesse opened a new pull request #10: feat: make base rules stricter & closer to semistandard

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

Re: [VOTE] Cordova-Common 3.2.1 Release

I vote +1 - CI is green - I reviewed the diff from 3.2.0..3.2.1 Am Mo., 28. Okt. 2019 um 11:13 Uhr schrieb Bryan Ellis : > Please review and vote on this Cordova Common Patch Release v3.2.1 > by replying to this email (and keep discussion on the DISCUSS thread) > > The archive has been

Re: [PROPOSAL] Cordova Plugin Audit System

I think this sounds quite interesting. I think the integration in CLI would be best handled as a plugin that provides an after_plugin_add hook that communicates with the service. That way we can keep the core lean and users have an easy way to enable/disable the service. If we want to endorse

Re: vote: PR merge convention

+1 for "Squash and merge" as the default strategy Regarding "Create a merge commit": At times, I find this option valuable too. Consider a PR that cleans up a test suite. As part of that cleanup I might re-order the test cases. As re-ordering produces a noisy diff, I usually isolate it in its own

Re: Cordova dev discussions on GitHub

I agree with Niklas that we should not increase the number of communication channels. Rather, we should try to better communicate the existence and the intended scopes of the ones we already have. Maybe even get rid of some of them. Niklas Merz schrieb am Mi., 19. Feb. 2020, 08:10: > I

Re: Checking all CONTRIBUTING.md files

Sounds good, Niklas. I suggest you create a PR in cordova-contribute[1] to work out the updated file contents. Then that file can be committed to all repositories. No PRs necessary for that IMHO. One thing to keep in mind is that repositories that are currently in a release vote should not have

Re: Short introduction as I joined the dev mailing list

Hi Mathias, I can second everything that Niklas said. Other than that I'd like to add that I already noticed your PR in cordova-js and from a first glance it looks like a good change to me. Unfortunately I'm currently swamped with non-Cordova work, so I haven't had the time to give it a proper

Re: Team page on Cordova website

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

Re: [Cordova dev] formal coding styles?

My suggestion would be to let @cordova/eslint-config be the single source of truth regarding JS code style. I do not like the idea of an additional document that duplicates this code style in prose. Instead, people should use the configured linting tools to check if their contribution matches our

Re: [VOTE] Cordova-ESLint 3.0.0 Release

I vote +1: * Ensured continuous build was green when repo was tagged * Tested tagged version against cordova-android * Tested uploaded version from dist/dev against cordova-android Am Di., 24. März 2020 um 05:32 Uhr schrieb Bryan Ellis : > Please review and vote on this Cordova ESLint Major

Re: Modernize cordova-android build?

Regarding Gradle: It would really be great if we could work around that "do not distribute JARs" requirement. A good first step would be to see the actual rule that forbids us to do this. In the thread Darryl linked to there was a message exploring some possible workarounds: > Can we cheat and

Re: [VOTE] cordova-js 6.1.0 Release

I vote +1: * CI was successful at tagged version * Set of changes is OK for a minor release * Uploaded tarball contains the expected files * cordova-electron#194 works with uploaded tarball Am Mo., 12. Juli 2021 um 06:30 Uhr schrieb Bryan

Re: [DISCUSS] cordova-fetch 3.0.1 patch release

+1 from me. A patch release would be appropriate IMHO. Thank you for pushing this forward, Darryl!  Am Di., 2. Feb. 2021 um 22:14 Uhr schrieb Darryl Pogue : > Hey folks, > > So npm v7 has hit general availability, and is now the default version of > npm[1]. This is a slight problem for us

Re: [DISCUSS] cordova-android 9.1.0 Minor Release

It would be great if we could include https://github.com/apache/cordova-android/pull/1101 in this release. It is just a pure refactoring/non-functional change PR but it sure would be great to merge and release it before it gets stale. I would have no concerns merging it as is, even without