[GitHub] cordova-docs pull request: Add Sworkit to Cordova App Showcase

[gylippus]

GitHub user gylippus opened a pull request:

https://github.com/apache/cordova-docs/pull/361

Add Sworkit to Cordova App Showcase

As requested, Sworkit has been added to the Cordova App Showcase

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gylippus/cordova-docs sworkit-showcase

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-docs/pull/361.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #361


commit 523889a844cb47663b4d2ec73b3fc9818f068732
Author: Ryan Hanna 
Date:   2015-09-23T11:04:20Z

adds Sworkit to Cordova App Showcase




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-plugin-contacts pull request: Get input stream from relati...

[vincipop]

GitHub user vincipop opened a pull request:

https://github.com/apache/cordova-plugin-contacts/pull/77

Get input stream from relative path

"Get an input stream based on file path or uri "  didn't work for relative 
paths so modified line 1635
The problem is still present for path started with "file:" (full path) : 
ToDo

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/vincipop/cordova-plugin-contacts master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-plugin-contacts/pull/77.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #77


commit 94d4a6eb7aadd16011c93c8c098cecd02f4ced1b
Author: vincipop 
Date:   2015-09-23T13:02:06Z

Update ContactAccessorSdk.java

"Get an input stream based on file path or uri "  didn't work for relative 
paths so modified line 1635
The problem is still present for path started with "file:" (full path) : 
ToDo

commit a19faee5772887e47d6f1988d7e3a9e2e5029da3
Author: vincipop 
Date:   2015-09-23T13:04:17Z

Merge pull request #1 from vincipop/vincipop-patch-1

Update ContactAccessorSdk.java for get input stream from relative path




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-lib pull request: icon parameter should not be relative to...

[david-barth-canonical]

Github user david-barth-canonical commented on the pull request:

https://github.com/apache/cordova-lib/pull/299#issuecomment-142564241
  
Yes, makes sense. Icon management needs more tweaks, but this way it will 
work better already Thanks for the review.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-medic pull request: CB-9660 Kill wp8.1 emulator in medic-k...

[alsorokin]

GitHub user alsorokin opened a pull request:

https://github.com/apache/cordova-medic/pull/66

CB-9660 Kill wp8.1 emulator in medic-kill on Windows

https://issues.apache.org/jira/browse/CB-9660

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/MSOpenTech/cordova-medic CB-9660

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-medic/pull/66.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #66


commit 51f8c7d49f54936a527cfff1e2e88edcf3c682d9
Author: Alexander Sorokin 
Date:   2015-09-23T12:40:57Z

CB-9660 Kill wp8.1 emulator in medic-kill on Windows




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-android pull request: CB-9608 cordova-android no longer bu...

[daserge]

GitHub user daserge opened a pull request:

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

CB-9608 cordova-android no longer builds on Node 0.10 or below

Replaced `path.isAbsolute` usage with `path.resolve`.

[Jira issue](https://issues.apache.org/jira/browse/CB-9608)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/MSOpenTech/cordova-android CB-9608

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-android/pull/215.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #215


commit dcab3df3c85444290e1a30c0b99c8caf8c68b6f9
Author: daserge 
Date:   2015-09-23T12:57:03Z

CB-9608 cordova-android no longer builds on Node 0.10 or below

Replaced path.isAbsolute usage with path.resolve




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-plugin-media pull request: audio-recorder-format-fix-html5

[krishlakshmanan]

GitHub user krishlakshmanan opened a pull request:

https://github.com/apache/cordova-plugin-media/pull/69

audio-recorder-format-fix-html5



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/krishlakshmanan/cordova-plugin-media 
audio-recorder-format-fix-html5

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-plugin-media/pull/69.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #69


commit 22fcd65cd770fdeaa59a3c6c49e66d118ad5f2f3
Author: Krish Lakshmanan 
Date:   2015-09-23T14:47:37Z

audio-recorder-format-fix-html5




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-medic pull request: CB-9695 Add a command to print globall...

[alsorokin]

GitHub user alsorokin opened a pull request:

https://github.com/apache/cordova-medic/pull/67

CB-9695 Add a command to print globally installed npm modules

https://issues.apache.org/jira/browse/CB-9695

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/MSOpenTech/cordova-medic CB-9695

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-medic/pull/67.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #67


commit 3dd8e44c8a8eaa10a2a52174da54568c279a3c0d
Author: Alexander Sorokin 
Date:   2015-09-23T14:49:41Z

CB-9695 Add a command to print globally installed npm modules




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-android pull request: CB-9608 cordova-android no longer bu...

[sgrebnov]

Github user sgrebnov commented on the pull request:

https://github.com/apache/cordova-android/pull/215#issuecomment-142625693
  
:+1: lgtm


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-plugin-media pull request: audio-recorder-format-fix-html5

[krishlakshmanan]

GitHub user krishlakshmanan opened a pull request:

https://github.com/apache/cordova-plugin-media/pull/70

audio-recorder-format-fix-html5



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/krishlakshmanan/cordova-plugin-media 
audio-recorder-format-fix-html5

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-plugin-media/pull/70.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #70


commit 22fcd65cd770fdeaa59a3c6c49e66d118ad5f2f3
Author: Krish Lakshmanan 
Date:   2015-09-23T14:47:37Z

audio-recorder-format-fix-html5




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-plugin-media pull request: audio-recorder-format-fix-html5

[krishlakshmanan]

Github user krishlakshmanan closed the pull request at:

https://github.com/apache/cordova-plugin-media/pull/69


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-android pull request: CB-9608 cordova-android no longer bu...

[daserge]

Github user daserge commented on the pull request:

https://github.com/apache/cordova-android/pull/215#issuecomment-142655973
  
Investigating path issues on a Mac, closing this for now.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-docs pull request: Implementing Proper Latest Docs Version

[riknoll]

Github user riknoll commented on the pull request:

https://github.com/apache/cordova-docs/pull/358#issuecomment-142657609
  
Looks good to me!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [Proposal][iOS] Drop support for iOS 7

[Carlos Santana]

Hi I like what I see in the Windows Platform repo README.md
https://github.com/apache/cordova-windows#requirements

They lis the Mobile OS that they support and the ones that still work but
deprecated.

I think it will be clear to have the same for the other platforms (i.e. ios
and android)

For iOS, we can say iOS7 deprecated, iOS8 and iOS9 supported
For Android, we can say Android 2.3 (less than API 14) not longer
supported, API 22 supported, when cordova-android@5 comes out then target
API 23 supported.

Then it's easier and more clear to determined what is the Mobile OS
supported for that specific version of the platform release.



On Mon, Sep 21, 2015 at 2:50 PM Raymond Camden 
wrote:

> +1. I read today that 50% of active devices are already on 9.
>
> On Mon, Sep 21, 2015 at 1:41 PM, Shazron  wrote:
> > Yeah I'm thinking cordova-ios 4.x should have this change.
> >
> > On Mon, Sep 21, 2015 at 11:36 AM, Simon MacDonald
> >  wrote:
> >> +1
> >>
> >> I like the idea of not actively breaking iOS 7 devices but not actively
> >> testing them. The last iPhone that is stuck on iOS 7 is the iPhone 4
> which
> >> is 4 years old at this point.
> >>
> >> Are you thinking Cordova iOS 4 to introduce thus change?
> >>
> >> Simon
> >> On Sep 21, 2015 2:29 PM, "Shazron"  wrote:
> >>
> >>> We tend to have this discussion every year. We've typically supported
> >>> the current iOS version and one version back. This would mean just
> >>> supporting iOS 9 and 8.
> >>>
> >>> I propose to drop support for iOS 7.
> >>>
> >>> This doesn't mean Cordova won't run on an iOS 7 device, but this means
> >>> we won't test whether Cordova or the plugins run on it (i.e. not crash
> >>> if they use a newer API).
> >>>
> >>> There is only one change required: Increasing the minimum
> >>> DEPLOYMENT_TARGET to 8.0 in the new project template/xcconfig.
> >>>
> >>>
> >>> According to Apple, 52% of devices are using iOS 9 already, and 41%
> >>> are on iOS 8. 8% of users are on earlier iOS versions. (Yeah the math
> >>> adds up to 101%??)
> >>> Source: https://developer.apple.com/support/app-store/
> >>>
> >>> -
> >>> 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
> >
>
>
>
> --
> ===
> Raymond Camden, Developer Advocate for MobileFirst at IBM
>
> Email : raymondcam...@gmail.com
> Blog : www.raymondcamden.com
> Twitter: raymondcamden
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: [Android] 5.0.x release branch?

[Carlos Santana]

No need to major version change for the Plugins, the API of the didn't
change.
Web developer still uses the same JS API to use the plugin.

Yes I did some thinking around the plugin search website. I think is a good
topic for the F2F.
Now that IBM is using Cordova Plugin more heavily to package our mobile
SDKs using Cordova Plugins, I think is beneficial to expose more info about
the plugin including engine tags

I would not go and build our own backend and have our own registry with
cordova metadata.

I think the solution is to put the metadata of plugin.xml into
package.json. We can show fast results in main search, but then user can
drill into the plugin details, and we can have a view with more information
and allow the user to select a specific version like we have today in our
plugin website search using the cordova registry.

The website can fetch the package.json and it will have the information to
display to the user.

So what I think we need to do is document and automate the information from
plugin.xml including engine tags into the package.json.

Today we have some sort of duplicate information between the "cordova" and
"keywords", I think it would be a good time to clean it up and add an array
in cordova.engines



On Wed, Sep 23, 2015 at 12:19 PM Nikhil Khandelwal 
wrote:

> Merging threads. I was no aware of any security implications of using
> reflection - Perhaps if the reflection target can be controlled through
> external data. In any case, I understand your hesitation with use of
> reflection. I would love to have longer discussions on the F2F on what
> approaches we could use to make this easier for Cordova developers.
>
> Joe: Could you add the appropriate engine tags in any case? That's how
> Cordova currently handles versioning between plugins & platforms. Also,
> does this imply that the plugins should have a major version bump as it is
> a breaking change? Please create the 5.x branches and if you could submit a
> PR - I had other minor code review comments on the diffs below.
>
> Carlos: I understand in the extreme case it can be a fairly complicated
> implementation with lots of criteria to use to determine the ideal plugin
> that might work given a set of platforms. However, trying a couple of
> previous versions of the plugins might work 80% of the time and that might
> be good enough. This requires more thought as there are quite a few
> scenarios here.
>
> As for plugin search website helping you find the correct engine tags - I
> like the idea. But this might requires us maintaining a backend for plugin
> search as this is specified in plugin.xml (and not package.json - or did we
> finally move this?).
>
> Thanks,
> Nikhil
>
> -Original Message-
> From: Carlos Santana [mailto:csantan...@gmail.com]
> Sent: Tuesday, September 22, 2015 6:14 PM
> To: dev@cordova.apache.org
> Subject: Re: [Android] 5.0.x release branch?
>
> +1 we should always use the engine tag to mark the minimum compatible
> +version at least
>
> -1 for cordova CLI to automagically to install an older version. It will
> be a pain to get this implemented right, we would need to download all the
> package.json for multiple versions of the plugin and pick the lowest common
> denominator based on engine tags and remember that one plugin support
> multiple engine tags across different platform versions and CLI/plugman.
>
> This brings an interesting feature to implement In the plugin search
> website, to display the engine tags for a specific plugin version. Allowing
> a developer to search for a compatible plugin for their current app.
>
> - Carlos
> Sent from my iPhone
>
>
> -Original Message-
> From: Joe Bowser [mailto:bows...@gmail.com]
> Sent: Tuesday, September 22, 2015 6:17 PM
> To: dev@cordova.apache.org
> Subject: Re: [Android] 5.0.x release branch?
>
> I'm completely against using reflection for this purpose.  Version codes
> were invented for a reason and we don't have any mechanism in place to unit
> test any Android code (or any other native code on any of the platforms).
>
> I will vote against any release that includes reflection for this purpose
> since reflection has only brought us security issues and extreme WebView
> breakage when used (Simon can tell you the tales of the HTC console.log
> reflection code.).  Reflection is a worst-case scenario tool like when a
> method in WebView marked as deprecated completely disappears, not something
> we should make a habit of using often.  If we open the door for this, we'll
> get reflection creeping elsewhere, like the Plugins API.
>
> Just say no to reflection.
>
>
> On Tue, Sep 22, 2015, 5:57 PM Nikhil Khandelwal 
> wrote:
>
> > Thanks, Joe for the detailed explanation. I understand why we've taken
> > this route. It's good that this is only a build failure. One of the
> > complaints we commonly hear from Cordova developers is that "I have a
> > cordova project with a certain version of 

[GitHub] cordova-android pull request: CB-9080 Cordova CLI run for Android ...

[daserge]

GitHub user daserge opened a pull request:

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

CB-9080 Cordova CLI run for Android versions 4.1.1 and lower throws e…

…rror

[Jira issue](https://issues.apache.org/jira/browse/CB-9080)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/MSOpenTech/cordova-android CB-9080

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-android/pull/216.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #216


commit afa61aeb0915fd4334d266bdfee759ab9bbb52db
Author: daserge 
Date:   2015-09-23T15:44:41Z

CB-9080 Cordova CLI run for Android versions 4.1.1 and lower throws error




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

RE: [Android] 5.0.x release branch?

[Nikhil Khandelwal]

Merging threads. I was no aware of any security implications of using 
reflection - Perhaps if the reflection target can be controlled through 
external data. In any case, I understand your hesitation with use of 
reflection. I would love to have longer discussions on the F2F on what 
approaches we could use to make this easier for Cordova developers.

Joe: Could you add the appropriate engine tags in any case? That's how Cordova 
currently handles versioning between plugins & platforms. Also, does this imply 
that the plugins should have a major version bump as it is a breaking change? 
Please create the 5.x branches and if you could submit a PR - I had other minor 
code review comments on the diffs below.

Carlos: I understand in the extreme case it can be a fairly complicated 
implementation with lots of criteria to use to determine the ideal plugin that 
might work given a set of platforms. However, trying a couple of previous 
versions of the plugins might work 80% of the time and that might be good 
enough. This requires more thought as there are quite a few scenarios here.

As for plugin search website helping you find the correct engine tags - I like 
the idea. But this might requires us maintaining a backend for plugin search as 
this is specified in plugin.xml (and not package.json - or did we finally move 
this?). 

Thanks,
Nikhil

-Original Message-
From: Carlos Santana [mailto:csantan...@gmail.com] 
Sent: Tuesday, September 22, 2015 6:14 PM
To: dev@cordova.apache.org
Subject: Re: [Android] 5.0.x release branch?

+1 we should always use the engine tag to mark the minimum compatible 
+version at least

-1 for cordova CLI to automagically to install an older version. It will be a 
pain to get this implemented right, we would need to download all the 
package.json for multiple versions of the plugin and pick the lowest common 
denominator based on engine tags and remember that one plugin support multiple 
engine tags across different platform versions and CLI/plugman. 

This brings an interesting feature to implement In the plugin search website, 
to display the engine tags for a specific plugin version. Allowing a developer 
to search for a compatible plugin for their current app. 

- Carlos
Sent from my iPhone


-Original Message-
From: Joe Bowser [mailto:bows...@gmail.com] 
Sent: Tuesday, September 22, 2015 6:17 PM
To: dev@cordova.apache.org
Subject: Re: [Android] 5.0.x release branch?

I'm completely against using reflection for this purpose.  Version codes were 
invented for a reason and we don't have any mechanism in place to unit test any 
Android code (or any other native code on any of the platforms).

I will vote against any release that includes reflection for this purpose since 
reflection has only brought us security issues and extreme WebView breakage 
when used (Simon can tell you the tales of the HTC console.log reflection 
code.).  Reflection is a worst-case scenario tool like when a method in WebView 
marked as deprecated completely disappears, not something we should make a 
habit of using often.  If we open the door for this, we'll get reflection 
creeping elsewhere, like the Plugins API.

Just say no to reflection.


On Tue, Sep 22, 2015, 5:57 PM Nikhil Khandelwal 
wrote:

> Thanks, Joe for the detailed explanation. I understand why we've taken 
> this route. It's good that this is only a build failure. One of the 
> complaints we commonly hear from Cordova developers is that "I have a 
> cordova project with a certain version of the platform, I need to find 
> the plugin that will work with it". Our CLI always defaults to add the 
> latest released version of the plugin.
>
> After this breaking change, an existing cordova project with 
> cordova-android < 5.x, cannot build with the latest version of the 
> following plugins:
> - camera
>- geolocation
>- contacts.
> These are some of the most popular plugins in cordova plugin ecosystem [1].
>
> I propose that we should do our best to avoid disruptive breaking 
> changes here. Some ideas that come to mind:
> - As Joe mentioned below - reflection. It has the downsides that Joe 
> mentioned. No one likes to write code like this it but results in 
> least grief for Cordova users. Some pain here for plugin developers 
> will simplify the experience for large number of corodva JS 
> developers. I know we are doing some of this in cordova-ios [2] and 
> would love to find ways on how to make this manageable and not super ugly.
> - Add an  ' '  to 
> the plugins - failure happens at plugin add in this scenario. 
> Cordova-lib could be more intelligent to detect this error and resort 
> to using an older version of the plugin. The downside of this is that 
> these projects cannot use the latest and greatest of these plugins.
>
> Thanks,
> Nikhil
>
> [1] 
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcordov
> 

[GitHub] cordova-android pull request: CB-9608 cordova-android no longer bu...

[daserge]

Github user daserge commented on the pull request:

https://github.com/apache/cordova-android/pull/217#issuecomment-142671130
  
This should work on OSX now as well (`path.join('.', 
'/some/abs/path.tofile')` was turning path to relative in #215 ).


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

RE: [DISCUSS] Tools Release

[Steven Gill]

Merged and sent you an invitation to have access to repo
On Sep 22, 2015 7:20 PM, "Sergey Grebnov (Akvelon)" 
wrote:

> Could someone merge the post or give me write access to the
> apache-blog-posts repo please.
> https://github.com/cordova/apache-blog-posts/pull/46
>
> I'll update npm after that.
>
> Thx!
> Sergey
> -Original Message-
> From: Sergey Grebnov (Akvelon)
> Sent: Tuesday, September 22, 2015 9:42 AM
> To: dev@cordova.apache.org
> Subject: RE: [DISCUSS] Tools Release
>
> Here is announce draft, please review
> https://github.com/cordova/apache-blog-posts/pull/46/
>
> Should we include link to JIRA issue for more details?
> https://issues.apache.org/jira/browse/CB-9297
>
> Thx!
> Sergey
> -Original Message-
> From: Vladimir Kotikov (Akvelon) [mailto:v-vlk...@microsoft.com]
> Sent: Friday, September 18, 2015 3:20 AM
> To: dev@cordova.apache.org
> Subject: RE: [DISCUSS] Tools Release
>
> The new thread has started. I had to bump patch versions for tools, so
> they now are:
> cordova-lib: 5.3.3 (932ad57858)
> cordova-plugman: 1.0.4 (0de514b4b1)
> cordova-cli: 5.3.3 (e647fe4382)
>
> Also, packages, broken when published from Windows seems to be known
> problem:
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fnpm%2fnpm%2fissues%2f2097=01%7c01%7cv-segreb%40microsoft.com%7cd9f82e0ca54a471d88c608d2c012d6c2%7c72f988bf86f141af91ab2d7cd011db47%7c1=zX8PqZr8%2fY2RRly4U9pl0eHLaSgrpqSwW8wpf5ZXVdg%3d
> Probably we might workaround this by pinning  'eol=crlf' for executable
> scripts through .gitattributes (there is a nice article from GitHub here:
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fhelp.github.com%2farticles%2fdealing-with-line-endings%2f=01%7c01%7cv-segreb%40microsoft.com%7cd9f82e0ca54a471d88c608d2c012d6c2%7c72f988bf86f141af91ab2d7cd011db47%7c1=O6Fverh%2fFbeXiPmW7kGfWswi8RAVvf8t4V7ZvfX8CUA%3d
> ). Any thoughts?
>
> -
> Best regards, Vladimir
>
> -Original Message-
> From: Vladimir Kotikov (Akvelon) [mailto:v-vlk...@microsoft.com]
> Sent: Thursday, September 17, 2015 5:10 PM
> To: dev@cordova.apache.org
> Subject: RE: [DISCUSS] Tools Release
>
> BTW, could anybody please grant me access to npmjs. I had to ask Sergey to
> publish packages to NPM.
>
> -
> Best regards, Vladimir
>
> -Original Message-
> From: Carlos Santana [mailto:csantan...@gmail.com]
> Sent: Thursday, September 17, 2015 4:57 PM
> To: dev@cordova.apache.org
> Subject: Re: [DISCUSS] Tools Release
>
> OK Vladimir
>
> On Thu, Sep 17, 2015 at 9:50 AM Vladimir Kotikov (Akvelon) <
> v-vlk...@microsoft.com> wrote:
>
> > Working on it
> > -
> > Best regards, Vladimir
> >
> > -Original Message-
> > From: Tommy-Carlos Williams [mailto:to...@devgeeks.org]
> > Sent: Thursday, September 17, 2015 4:01 PM
> > To: dev@cordova.apache.org
> > Subject: Re: [DISCUSS] Tools Release
> >
> > Were we waiting on a vote? I would +1
> >
> > > On 17 Sep 2015, at 22:50, Carlos Santana  wrote:
> > >
> > > A day has pass and no sign of a vote for the emergency fix.
> > >
> > > Why not just do a tools release with everything it's in master today?
> > > in theory we should be able to do a release of what's in master at
> > > any time
> > >
> > >
> > > On Thu, Sep 17, 2015 at 5:29 AM Vladimir Kotikov (Akvelon) <
> > > v-vlk...@microsoft.com> wrote:
> > >
> > >> I believe this is not a blocker. We have platforms pinned with
> > >> tilde, so platform's patch release will be picked up automatically.
> > >>
> > >> -
> > >> Best regards, Vladimir
> > >>
> > >> -Original Message-
> > >> From: Tommy Williams [mailto:to...@devgeeks.org]
> > >> Sent: Thursday, September 17, 2015 7:59 AM
> > >> To: dev@cordova.apache.org
> > >> Subject: Re: [DISCUSS] Tools Release
> > >>
> > >> I have a cherry pick to cordova-ios[1] that would be good to be
> > >> included in 5.3.2 if there are already plans to update iOS’s pinned
> > >> version…
> > >>
> > >> 1.
> > >> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fis
> > >> su
> > >> es.apache.org%2fjira%2fbrowse%2fCB-9046=01%7c01%7cv-vlkoti%400
> > >> 64
> > >> d.mgd.microsoft.com%7cc74c34192a664443cce908d2bf1cc69b%7c72f988bf86
> > >> f1
> > >> 41af91ab2d7cd011db47%7c1=M%2f1jcQ0q3%2bllZYMoSsU0dHNrX12No0fK
> > >> 5H
> > >> lcW3C13mg%3d
> > >>
> > >>
> > >> On 17 September 2015 at 03:46:52, Carlos Santana
> > >> (csantan...@gmail.com)
> > >> wrote:
> > >>
> > >> +1
> > >>
> > >> There are more commits seating in master, Should we plan for
> > >> another release right after releasing the cherry-pick release for
> nodejs@4?
> > >>
> > >>
> > >> On Wed, Sep 16, 2015 at 11:25 AM Steven Gill
> > >> 
> > >> wrote:
> > >>
> > >>> Good idea with the cherry-pick.
> > >>> On Sep 16, 2015 8:07 AM, "Sergey Grebnov (Akvelon)" <
> > >>> v-seg...@microsoft.com>
> > >>> wrote:
> > >>>
> >  We currently have iOS and Node v4 compatibility issue[1] which
> > 

[GitHub] cordova-docs pull request: Adding Syntax Highlighting to Site

[riknoll]

Github user riknoll commented on the pull request:

https://github.com/apache/cordova-docs/pull/359#issuecomment-142652316
  
Looks good to me!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-android pull request: CB-9608 cordova-android no longer bu...

[daserge]

Github user daserge closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-docs pull request: Adding Syntax Highlighting to Site

[riknoll]

Github user riknoll commented on a diff in the pull request:

https://github.com/apache/cordova-docs/pull/359#discussion_r40224664
  
--- Diff: _config.yml ---
@@ -26,7 +26,13 @@ keep_files: [".git", ".svn", "wiki-images", "images", 
"downloads"]
 lsi:  false # don't produce an index for related posts
 safe: true  # disables plugins
 
-markdown: kramdown
+markdown: redcarpet
+
+redcarpet:
+extensions:
+- prettify
+- fenced_code_blocks
--- End diff --

Nitpick: fenced_code_blocks is set to be true by default in Jekyll. We 
don't need to specify it: http://jekyllrb.com/docs/configuration/#redcarpet


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-android pull request: CB-9080 Cordova CLI run for Android ...

[nikhilkh]

Github user nikhilkh commented on the pull request:

https://github.com/apache/cordova-android/pull/216#issuecomment-142654150
  
LGTM


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-android pull request: CB-9608 cordova-android no longer bu...

[daserge]

GitHub user daserge opened a pull request:

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

CB-9608 cordova-android no longer builds on Node 0.10 or below

Replaced `path.isAbsolute` usage with `path.resolve`.

[Jira issue](https://issues.apache.org/jira/browse/CB-9608)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/MSOpenTech/cordova-android CB-9608

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-android/pull/217.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #217


commit c32d47ad06e29a1fd3cbd3241b46d19bb1683692
Author: daserge 
Date:   2015-09-23T12:57:03Z

CB-9608 cordova-android no longer builds on Node 0.10 or below

Replaced path.isAbsolute usage with path.resolve




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [Android] 5.0.x release branch?

[Joe Bowser]

On Wed, Sep 23, 2015 at 9:36 AM, Carlos Santana 
wrote:

> No need to major version change for the Plugins, the API of the didn't
> change.
> Web developer still uses the same JS API to use the plugin.
>
>
I would do a major version bump on Geolocation.  The API itself didn't
change but the behaviour certainly did.  On Marshmallow we have to add this
extra shim that asks for permission, which means that there's now code
attached to Android Geolocation that didn't exist before.  All the other
plugins should still be fine.


> Yes I did some thinking around the plugin search website. I think is a good
> topic for the F2F.
> Now that IBM is using Cordova Plugin more heavily to package our mobile
> SDKs using Cordova Plugins, I think is beneficial to expose more info about
> the plugin including engine tags
>
> I would not go and build our own backend and have our own registry with
> cordova metadata.
>
> I think the solution is to put the metadata of plugin.xml into
> package.json. We can show fast results in main search, but then user can
> drill into the plugin details, and we can have a view with more information
> and allow the user to select a specific version like we have today in our
> plugin website search using the cordova registry.
>
> The website can fetch the package.json and it will have the information to
> display to the user.
>
> So what I think we need to do is document and automate the information from
> plugin.xml including engine tags into the package.json.
>
> Today we have some sort of duplicate information between the "cordova" and
> "keywords", I think it would be a good time to clean it up and add an array
> in cordova.engines
>
>
>
> On Wed, Sep 23, 2015 at 12:19 PM Nikhil Khandelwal  >
> wrote:
>
> > Merging threads. I was no aware of any security implications of using
> > reflection - Perhaps if the reflection target can be controlled through
> > external data. In any case, I understand your hesitation with use of
> > reflection. I would love to have longer discussions on the F2F on what
> > approaches we could use to make this easier for Cordova developers.
> >
> > Joe: Could you add the appropriate engine tags in any case? That's how
> > Cordova currently handles versioning between plugins & platforms. Also,
> > does this imply that the plugins should have a major version bump as it
> is
> > a breaking change? Please create the 5.x branches and if you could
> submit a
> > PR - I had other minor code review comments on the diffs below.
> >
> > Carlos: I understand in the extreme case it can be a fairly complicated
> > implementation with lots of criteria to use to determine the ideal plugin
> > that might work given a set of platforms. However, trying a couple of
> > previous versions of the plugins might work 80% of the time and that
> might
> > be good enough. This requires more thought as there are quite a few
> > scenarios here.
> >
> > As for plugin search website helping you find the correct engine tags - I
> > like the idea. But this might requires us maintaining a backend for
> plugin
> > search as this is specified in plugin.xml (and not package.json - or did
> we
> > finally move this?).
> >
> > Thanks,
> > Nikhil
> >
> > -Original Message-
> > From: Carlos Santana [mailto:csantan...@gmail.com]
> > Sent: Tuesday, September 22, 2015 6:14 PM
> > To: dev@cordova.apache.org
> > Subject: Re: [Android] 5.0.x release branch?
> >
> > +1 we should always use the engine tag to mark the minimum compatible
> > +version at least
> >
> > -1 for cordova CLI to automagically to install an older version. It will
> > be a pain to get this implemented right, we would need to download all
> the
> > package.json for multiple versions of the plugin and pick the lowest
> common
> > denominator based on engine tags and remember that one plugin support
> > multiple engine tags across different platform versions and CLI/plugman.
> >
> > This brings an interesting feature to implement In the plugin search
> > website, to display the engine tags for a specific plugin version.
> Allowing
> > a developer to search for a compatible plugin for their current app.
> >
> > - Carlos
> > Sent from my iPhone
> >
> >
> > -Original Message-
> > From: Joe Bowser [mailto:bows...@gmail.com]
> > Sent: Tuesday, September 22, 2015 6:17 PM
> > To: dev@cordova.apache.org
> > Subject: Re: [Android] 5.0.x release branch?
> >
> > I'm completely against using reflection for this purpose.  Version codes
> > were invented for a reason and we don't have any mechanism in place to
> unit
> > test any Android code (or any other native code on any of the platforms).
> >
> > I will vote against any release that includes reflection for this purpose
> > since reflection has only brought us security issues and extreme WebView
> > breakage when used (Simon can tell you the tales of the HTC console.log
> > reflection code.).  Reflection is a worst-case scenario tool like 

Re: Cordova website redesign

[Steven Gill]

Awesome!

We might want to add more apps to showcase before we push it live.

Love the focus on quickstart.

We can probably remove tizen from
http://cordova.apache.org/use-the-force-luke/docs/en/edge/guide/support/index.html

Docs site looks good! I like the edit button which takes you to the github
mirror.

Plugins site is essentially replacing/using the new plugins search that
Murat built. For sorting, what does quality do?

Blog looks to be out of date. Like that you have the twitter feed on the
right.

I'm okay with this going live soon.

Great job everyone who worked on this site!

-Steve



On Wed, Sep 23, 2015 at 11:02 AM, Ryan J. Salva 
wrote:

> TLDR
>
> -- Feedback requested for a proposed Cordova website redesign at
> http://cordova.apache.org/use-the-force-luke
>
> -- The redesign was influenced by interviews with 300+ mobile
> developers. From these conversations, we identified six top level
> goals:
>
> 1. Establish that Cordova is an active project relevant to developers
> in 2016 (the future!)
>
> 2. Show the potential of hybrid apps by highlighting some rock
> star-quality apps
>
> 3. Demonstrate critical mass by sharing a diverse set of tools and
> businesses that have “made a bet” on Cordova
>
> 4. Improve developer’s first experience with Cordova by adding quick
> start instructions and explanatory text for key concepts (e.g.
> plugins)
>
> 5. Increase community participation by raising the visibility of
> public forums (e.g. Slack, StackOverflow, Twitter)
>
> 6. Maintain consistency with the current website (i.e. branding and
> content parity)
>
>
>  The long read 
>
> Grab a cup of coffee. This is a long one.
>
> As some of you may know, several committers from the Seattle area
> (including Nikhil, Parashuram and I) have just completed a long series
> of interviews with mobile developers. In the past three months, I’ve
> personally interviewed over 100 developers. The team has collectively
> interviewed closer to 300. We learned a lot and hope to share a
> summary (with infographics!) of our insights soon. In the meantime, I
> want to share one of the more poignant quotes from one interview. When
> asked, “How can we make your job easier?”, one Cordova developer
> responded:
>
>
> “Take the stigma away from hybrid development. I can prove that it’s
> the right tool for the job, but I have to prove it over-and-over
> again. I wish that I didn’t have to have the same conversation every
> time I want to use Cordova with a new manager or client.” -- Murali,
> Cordova Developer
>
>
> There are lots of ways to solve this problem, but one of the easier
> and more visible ways is through Cordova’s front-door. The Cordova
> website has served us well for the last 5+ years, but I believe a
> redesign could help us address some pain points in the community. To
> put it simply, we have a public perception problem.
>
>
> “It’s hard to argue for Cordova when there are few examples of it
> being successfully used.” -- Gary, Ionic Developer
>
>
> Developers and architects are looking for examples of good development
> to prove that high-quality, fast apps are possible. So, we thought it
> might be good to highlight some rock star-quality apps on the home
> page. Anyone can submit a PR to add their app so long as it appears in
> a public store and uses Cordova. If the list of apps gets too long
> (and it will), then we’ll randomize display. The same is true for a
> list of tools and platforms that build on top of Cordova.
>
>
> “There are so many layers to cross-platform development, it’s hard to
> know how they all fit together. It’s even harder to know if you’re
> missing a critical piece.” -- Mike, Cordova Developer
>
>
> By itself, the website redesign won’t address this problem. We need
> some good architectural docs that not only illustrate how Cordova
> works, but also how it integrates with the larger ecosystem (e.g.
> Crosswalk). However, we’re also hoping that by adding a little more
> “hand-holding” on the site, we can help developers achieve success
> faster. For example, we provide simple instructions for “Getting
> Started” on the home page. And, on the Plugins page, we provide a
> quick explanation of plugins’ role in Cordova development.
>
>
> “It’s not clear where I can go for support.” -- Geoff, Cordova Developer
>
>
> Okay…  none of us want to provide customer support for the whole
> community, but I want to make it easy for people to find the
> community. To that end, our goal was to integrate prominent pointers
> to all the places where our community aggregates – e.g. Slack,
> StackOverflow, JIRA and mailing list.
>
> Change for the sake of change is… well, for people with more time on
> their hands than me, but this seems like the right time for a change
> to the Cordova website. There’s a compelling developer need and little
> risk in making the change.
>
> Barring any grievous concerns, I'd love to get the new site launched
> ASAP. If we need to 

[GitHub] cordova-plugin-file pull request: fix install on amazon-fireos

[tomstgeorge]

Github user tomstgeorge commented on the pull request:


https://github.com/apache/cordova-plugin-file/pull/113#issuecomment-142695583
  
Trying again to get my app working on amazon-fireos. Using this fix I know 
get this when trying to build

```
   [javac] 
/Library/MobileApps/testfire/platforms/amazon-fireos/src/org/apache/cordova/file/LocalFilesystem.java:414:
 error: cannot find symbol
[javac] if (Build.VERSION.SDK_INT >= 
Build.VERSION_CODES.LOLLIPOP) {
[javac] ^
[javac]   symbol:   variable LOLLIPOP
[javac]   location: class VERSION_CODES
[javac] 
/Library/MobileApps/testfire/platforms/amazon-fireos/src/org/apache/cordova/file/LocalFilesystem.java:415:
 error: cannot find symbol
[javac] for (File f : context.getExternalMediaDirs()) {
[javac]  ^
[javac]   symbol:   method getExternalMediaDirs()
[javac]   location: variable context of type Context
```


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Cordova website redesign

[Ryan J. Salva]

TLDR

-- Feedback requested for a proposed Cordova website redesign at
http://cordova.apache.org/use-the-force-luke

-- The redesign was influenced by interviews with 300+ mobile
developers. From these conversations, we identified six top level
goals:

1. Establish that Cordova is an active project relevant to developers
in 2016 (the future!)

2. Show the potential of hybrid apps by highlighting some rock star-quality apps

3. Demonstrate critical mass by sharing a diverse set of tools and
businesses that have “made a bet” on Cordova

4. Improve developer’s first experience with Cordova by adding quick
start instructions and explanatory text for key concepts (e.g.
plugins)

5. Increase community participation by raising the visibility of
public forums (e.g. Slack, StackOverflow, Twitter)

6. Maintain consistency with the current website (i.e. branding and
content parity)


 The long read 

Grab a cup of coffee. This is a long one.

As some of you may know, several committers from the Seattle area
(including Nikhil, Parashuram and I) have just completed a long series
of interviews with mobile developers. In the past three months, I’ve
personally interviewed over 100 developers. The team has collectively
interviewed closer to 300. We learned a lot and hope to share a
summary (with infographics!) of our insights soon. In the meantime, I
want to share one of the more poignant quotes from one interview. When
asked, “How can we make your job easier?”, one Cordova developer
responded:


“Take the stigma away from hybrid development. I can prove that it’s
the right tool for the job, but I have to prove it over-and-over
again. I wish that I didn’t have to have the same conversation every
time I want to use Cordova with a new manager or client.” -- Murali,
Cordova Developer


There are lots of ways to solve this problem, but one of the easier
and more visible ways is through Cordova’s front-door. The Cordova
website has served us well for the last 5+ years, but I believe a
redesign could help us address some pain points in the community. To
put it simply, we have a public perception problem.


“It’s hard to argue for Cordova when there are few examples of it
being successfully used.” -- Gary, Ionic Developer


Developers and architects are looking for examples of good development
to prove that high-quality, fast apps are possible. So, we thought it
might be good to highlight some rock star-quality apps on the home
page. Anyone can submit a PR to add their app so long as it appears in
a public store and uses Cordova. If the list of apps gets too long
(and it will), then we’ll randomize display. The same is true for a
list of tools and platforms that build on top of Cordova.


“There are so many layers to cross-platform development, it’s hard to
know how they all fit together. It’s even harder to know if you’re
missing a critical piece.” -- Mike, Cordova Developer


By itself, the website redesign won’t address this problem. We need
some good architectural docs that not only illustrate how Cordova
works, but also how it integrates with the larger ecosystem (e.g.
Crosswalk). However, we’re also hoping that by adding a little more
“hand-holding” on the site, we can help developers achieve success
faster. For example, we provide simple instructions for “Getting
Started” on the home page. And, on the Plugins page, we provide a
quick explanation of plugins’ role in Cordova development.


“It’s not clear where I can go for support.” -- Geoff, Cordova Developer


Okay…  none of us want to provide customer support for the whole
community, but I want to make it easy for people to find the
community. To that end, our goal was to integrate prominent pointers
to all the places where our community aggregates – e.g. Slack,
StackOverflow, JIRA and mailing list.

Change for the sake of change is… well, for people with more time on
their hands than me, but this seems like the right time for a change
to the Cordova website. There’s a compelling developer need and little
risk in making the change.

Barring any grievous concerns, I'd love to get the new site launched
ASAP. If we need to make small changes after launch, it will be easy
to iterate. If you see any bugs that need to be fixed, please file
them here:

https://issues.apache.org/jira/browse/CB/component/12320562/

I open the floor to discussion ;-)

http://cordova.apache.org/use-the-force-luke


Thanks!
Ryan J. Salva

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

[GitHub] cordova-ios pull request: CB-9690 Can't submit iPad apps to the Ap...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-ios/pull/167


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-medic pull request: CB-9695 Add a command to print globall...

[dblotsky]

Github user dblotsky commented on the pull request:

https://github.com/apache/cordova-medic/pull/67#issuecomment-142687647
  
I don't think this needs a medic.js command. You can just run `npm ls -g` 
and add it to `CORDOVA_STEPS_SET_SETTINGS`.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [Android] 5.0.x release branch?

[Homer, Tony]

Joe-

As far as I can tell, the API 23 calls are currently unguarded so smores
will only work on M Preview.
I know your smores branch is a POC, but I was wondering about backwards
compatibility.
Do you anticipate adding Build.VERSION.SDK_INT >= Build.VERSION_CODES.M
guard clauses for backwards compatibility?

Tony

On 9/23/15, 1:56 PM, "Joe Bowser"  wrote:

>On Wed, Sep 23, 2015 at 9:36 AM, Carlos Santana 
>wrote:
>
>> No need to major version change for the Plugins, the API of the didn't
>> change.
>> Web developer still uses the same JS API to use the plugin.
>>
>>
>I would do a major version bump on Geolocation.  The API itself didn't
>change but the behaviour certainly did.  On Marshmallow we have to add
>this
>extra shim that asks for permission, which means that there's now code
>attached to Android Geolocation that didn't exist before.  All the other
>plugins should still be fine.
>
>
>> Yes I did some thinking around the plugin search website. I think is a
>>good
>> topic for the F2F.
>> Now that IBM is using Cordova Plugin more heavily to package our mobile
>> SDKs using Cordova Plugins, I think is beneficial to expose more info
>>about
>> the plugin including engine tags
>>
>> I would not go and build our own backend and have our own registry with
>> cordova metadata.
>>
>> I think the solution is to put the metadata of plugin.xml into
>> package.json. We can show fast results in main search, but then user can
>> drill into the plugin details, and we can have a view with more
>>information
>> and allow the user to select a specific version like we have today in
>>our
>> plugin website search using the cordova registry.
>>
>> The website can fetch the package.json and it will have the information
>>to
>> display to the user.
>>
>> So what I think we need to do is document and automate the information
>>from
>> plugin.xml including engine tags into the package.json.
>>
>> Today we have some sort of duplicate information between the "cordova"
>>and
>> "keywords", I think it would be a good time to clean it up and add an
>>array
>> in cordova.engines
>>
>>
>>
>> On Wed, Sep 23, 2015 at 12:19 PM Nikhil Khandelwal
>>> >
>> wrote:
>>
>> > Merging threads. I was no aware of any security implications of using
>> > reflection - Perhaps if the reflection target can be controlled
>>through
>> > external data. In any case, I understand your hesitation with use of
>> > reflection. I would love to have longer discussions on the F2F on what
>> > approaches we could use to make this easier for Cordova developers.
>> >
>> > Joe: Could you add the appropriate engine tags in any case? That's how
>> > Cordova currently handles versioning between plugins & platforms.
>>Also,
>> > does this imply that the plugins should have a major version bump as
>>it
>> is
>> > a breaking change? Please create the 5.x branches and if you could
>> submit a
>> > PR - I had other minor code review comments on the diffs below.
>> >
>> > Carlos: I understand in the extreme case it can be a fairly
>>complicated
>> > implementation with lots of criteria to use to determine the ideal
>>plugin
>> > that might work given a set of platforms. However, trying a couple of
>> > previous versions of the plugins might work 80% of the time and that
>> might
>> > be good enough. This requires more thought as there are quite a few
>> > scenarios here.
>> >
>> > As for plugin search website helping you find the correct engine tags
>>- I
>> > like the idea. But this might requires us maintaining a backend for
>> plugin
>> > search as this is specified in plugin.xml (and not package.json - or
>>did
>> we
>> > finally move this?).
>> >
>> > Thanks,
>> > Nikhil
>> >
>> > -Original Message-
>> > From: Carlos Santana [mailto:csantan...@gmail.com]
>> > Sent: Tuesday, September 22, 2015 6:14 PM
>> > To: dev@cordova.apache.org
>> > Subject: Re: [Android] 5.0.x release branch?
>> >
>> > +1 we should always use the engine tag to mark the minimum compatible
>> > +version at least
>> >
>> > -1 for cordova CLI to automagically to install an older version. It
>>will
>> > be a pain to get this implemented right, we would need to download all
>> the
>> > package.json for multiple versions of the plugin and pick the lowest
>> common
>> > denominator based on engine tags and remember that one plugin support
>> > multiple engine tags across different platform versions and
>>CLI/plugman.
>> >
>> > This brings an interesting feature to implement In the plugin search
>> > website, to display the engine tags for a specific plugin version.
>> Allowing
>> > a developer to search for a compatible plugin for their current app.
>> >
>> > - Carlos
>> > Sent from my iPhone
>> >
>> >
>> > -Original Message-
>> > From: Joe Bowser [mailto:bows...@gmail.com]
>> > Sent: Tuesday, September 22, 2015 6:17 PM
>> > To: dev@cordova.apache.org
>> > Subject: Re: [Android] 5.0.x release branch?
>> >
>> > I'm 

Re: [Android] 5.0.x release branch?

[Joe Bowser]

On Wed, Sep 23, 2015 at 11:30 AM, Joe Bowser  wrote:

>
> On Wed, Sep 23, 2015 at 11:22 AM, Homer, Tony 
> wrote:
>
>> Joe-
>>
>> As far as I can tell, the API 23 calls are currently unguarded so smores
>> will only work on M Preview.
>> I know your smores branch is a POC, but I was wondering about backwards
>> compatibility.
>> Do you anticipate adding Build.VERSION.SDK_INT >= Build.VERSION_CODES.M
>> guard clauses for backwards compatibility?
>>
>>
> This already exists in each of the plugins when they do the permissions
> check, and smores works perfectly fine on Lollipop so far.  Right now, if
> you aren't running M, you don't do the permissions check, and you don't
> call the methods.  I haven't tested it on earlier versions of Android, but
> I expect it to work on Kitkat and Jellybean the same way.
>
>
>

And yes, we can probably create a utility method, that said, most plugins
aren't directly affected by this, only the ones that require extra
permissions.  It'd be good if we had an idea of what third party plugins
people are actually using that would run afowl of this and see where they
would fail.  But I already have more than enough work currently, and
adopting other people's plugins is not something I want to get in the habit
of doing.



> Tony
>>
>> On 9/23/15, 1:56 PM, "Joe Bowser"  wrote:
>>
>> >On Wed, Sep 23, 2015 at 9:36 AM, Carlos Santana 
>> >wrote:
>> >
>> >> No need to major version change for the Plugins, the API of the didn't
>> >> change.
>> >> Web developer still uses the same JS API to use the plugin.
>> >>
>> >>
>> >I would do a major version bump on Geolocation.  The API itself didn't
>> >change but the behaviour certainly did.  On Marshmallow we have to add
>> >this
>> >extra shim that asks for permission, which means that there's now code
>> >attached to Android Geolocation that didn't exist before.  All the other
>> >plugins should still be fine.
>> >
>> >
>> >> Yes I did some thinking around the plugin search website. I think is a
>> >>good
>> >> topic for the F2F.
>> >> Now that IBM is using Cordova Plugin more heavily to package our mobile
>> >> SDKs using Cordova Plugins, I think is beneficial to expose more info
>> >>about
>> >> the plugin including engine tags
>> >>
>> >> I would not go and build our own backend and have our own registry with
>> >> cordova metadata.
>> >>
>> >> I think the solution is to put the metadata of plugin.xml into
>> >> package.json. We can show fast results in main search, but then user
>> can
>> >> drill into the plugin details, and we can have a view with more
>> >>information
>> >> and allow the user to select a specific version like we have today in
>> >>our
>> >> plugin website search using the cordova registry.
>> >>
>> >> The website can fetch the package.json and it will have the information
>> >>to
>> >> display to the user.
>> >>
>> >> So what I think we need to do is document and automate the information
>> >>from
>> >> plugin.xml including engine tags into the package.json.
>> >>
>> >> Today we have some sort of duplicate information between the "cordova"
>> >>and
>> >> "keywords", I think it would be a good time to clean it up and add an
>> >>array
>> >> in cordova.engines
>> >>
>> >>
>> >>
>> >> On Wed, Sep 23, 2015 at 12:19 PM Nikhil Khandelwal
>> >>> >> >
>> >> wrote:
>> >>
>> >> > Merging threads. I was no aware of any security implications of using
>> >> > reflection - Perhaps if the reflection target can be controlled
>> >>through
>> >> > external data. In any case, I understand your hesitation with use of
>> >> > reflection. I would love to have longer discussions on the F2F on
>> what
>> >> > approaches we could use to make this easier for Cordova developers.
>> >> >
>> >> > Joe: Could you add the appropriate engine tags in any case? That's
>> how
>> >> > Cordova currently handles versioning between plugins & platforms.
>> >>Also,
>> >> > does this imply that the plugins should have a major version bump as
>> >>it
>> >> is
>> >> > a breaking change? Please create the 5.x branches and if you could
>> >> submit a
>> >> > PR - I had other minor code review comments on the diffs below.
>> >> >
>> >> > Carlos: I understand in the extreme case it can be a fairly
>> >>complicated
>> >> > implementation with lots of criteria to use to determine the ideal
>> >>plugin
>> >> > that might work given a set of platforms. However, trying a couple of
>> >> > previous versions of the plugins might work 80% of the time and that
>> >> might
>> >> > be good enough. This requires more thought as there are quite a few
>> >> > scenarios here.
>> >> >
>> >> > As for plugin search website helping you find the correct engine tags
>> >>- I
>> >> > like the idea. But this might requires us maintaining a backend for
>> >> plugin
>> >> > search as this is specified in plugin.xml (and not package.json - or
>> >>did
>> >> we
>> >> > finally move 

[GitHub] cordova-docs pull request: Adding Syntax Highlighting to Site

[dblotsky]

Github user dblotsky commented on a diff in the pull request:

https://github.com/apache/cordova-docs/pull/359#discussion_r40237793
  
--- Diff: _config.yml ---
@@ -26,7 +26,13 @@ keep_files: [".git", ".svn", "wiki-images", "images", 
"downloads"]
 lsi:  false # don't produce an index for related posts
 safe: true  # disables plugins
 
-markdown: kramdown
+markdown: redcarpet
+
+redcarpet:
+extensions:
+- prettify
+- fenced_code_blocks
--- End diff --

If that default behaviour changes, specifying it here makes it clear that 
we explicitly want it. I'll add a comment to explain this.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-medic pull request: CB-9660 Kill wp8.1 emulator in medic-k...

[dblotsky]

Github user dblotsky commented on the pull request:

https://github.com/apache/cordova-medic/pull/66#issuecomment-142686868
  
Just a thought: are WP8 and WP8.1 emulators using the same process?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-lib pull request: icon parameter should not be relative to...

[tsschaffert]

Github user tsschaffert commented on the pull request:

https://github.com/apache/cordova-lib/pull/299#issuecomment-142535031
  
Shouldn't this be handled similar to how it is done in the manifest 
generation of cordova-ubuntu? Then the 'www' part should be replaced by '../..' 
(otherwise icons in a top-level res folder are not found).

See 
https://github.com/apache/cordova-ubuntu/blob/master/bin/templates/project/cordova/lib/manifest.js#L48


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [Android] 5.0.x release branch?

[Joe Bowser]

On Wed, Sep 23, 2015 at 11:22 AM, Homer, Tony  wrote:

> Joe-
>
> As far as I can tell, the API 23 calls are currently unguarded so smores
> will only work on M Preview.
> I know your smores branch is a POC, but I was wondering about backwards
> compatibility.
> Do you anticipate adding Build.VERSION.SDK_INT >= Build.VERSION_CODES.M
> guard clauses for backwards compatibility?
>
>
This already exists in each of the plugins when they do the permissions
check, and smores works perfectly fine on Lollipop so far.  Right now, if
you aren't running M, you don't do the permissions check, and you don't
call the methods.  I haven't tested it on earlier versions of Android, but
I expect it to work on Kitkat and Jellybean the same way.



> Tony
>
> On 9/23/15, 1:56 PM, "Joe Bowser"  wrote:
>
> >On Wed, Sep 23, 2015 at 9:36 AM, Carlos Santana 
> >wrote:
> >
> >> No need to major version change for the Plugins, the API of the didn't
> >> change.
> >> Web developer still uses the same JS API to use the plugin.
> >>
> >>
> >I would do a major version bump on Geolocation.  The API itself didn't
> >change but the behaviour certainly did.  On Marshmallow we have to add
> >this
> >extra shim that asks for permission, which means that there's now code
> >attached to Android Geolocation that didn't exist before.  All the other
> >plugins should still be fine.
> >
> >
> >> Yes I did some thinking around the plugin search website. I think is a
> >>good
> >> topic for the F2F.
> >> Now that IBM is using Cordova Plugin more heavily to package our mobile
> >> SDKs using Cordova Plugins, I think is beneficial to expose more info
> >>about
> >> the plugin including engine tags
> >>
> >> I would not go and build our own backend and have our own registry with
> >> cordova metadata.
> >>
> >> I think the solution is to put the metadata of plugin.xml into
> >> package.json. We can show fast results in main search, but then user can
> >> drill into the plugin details, and we can have a view with more
> >>information
> >> and allow the user to select a specific version like we have today in
> >>our
> >> plugin website search using the cordova registry.
> >>
> >> The website can fetch the package.json and it will have the information
> >>to
> >> display to the user.
> >>
> >> So what I think we need to do is document and automate the information
> >>from
> >> plugin.xml including engine tags into the package.json.
> >>
> >> Today we have some sort of duplicate information between the "cordova"
> >>and
> >> "keywords", I think it would be a good time to clean it up and add an
> >>array
> >> in cordova.engines
> >>
> >>
> >>
> >> On Wed, Sep 23, 2015 at 12:19 PM Nikhil Khandelwal
> >> >> >
> >> wrote:
> >>
> >> > Merging threads. I was no aware of any security implications of using
> >> > reflection - Perhaps if the reflection target can be controlled
> >>through
> >> > external data. In any case, I understand your hesitation with use of
> >> > reflection. I would love to have longer discussions on the F2F on what
> >> > approaches we could use to make this easier for Cordova developers.
> >> >
> >> > Joe: Could you add the appropriate engine tags in any case? That's how
> >> > Cordova currently handles versioning between plugins & platforms.
> >>Also,
> >> > does this imply that the plugins should have a major version bump as
> >>it
> >> is
> >> > a breaking change? Please create the 5.x branches and if you could
> >> submit a
> >> > PR - I had other minor code review comments on the diffs below.
> >> >
> >> > Carlos: I understand in the extreme case it can be a fairly
> >>complicated
> >> > implementation with lots of criteria to use to determine the ideal
> >>plugin
> >> > that might work given a set of platforms. However, trying a couple of
> >> > previous versions of the plugins might work 80% of the time and that
> >> might
> >> > be good enough. This requires more thought as there are quite a few
> >> > scenarios here.
> >> >
> >> > As for plugin search website helping you find the correct engine tags
> >>- I
> >> > like the idea. But this might requires us maintaining a backend for
> >> plugin
> >> > search as this is specified in plugin.xml (and not package.json - or
> >>did
> >> we
> >> > finally move this?).
> >> >
> >> > Thanks,
> >> > Nikhil
> >> >
> >> > -Original Message-
> >> > From: Carlos Santana [mailto:csantan...@gmail.com]
> >> > Sent: Tuesday, September 22, 2015 6:14 PM
> >> > To: dev@cordova.apache.org
> >> > Subject: Re: [Android] 5.0.x release branch?
> >> >
> >> > +1 we should always use the engine tag to mark the minimum compatible
> >> > +version at least
> >> >
> >> > -1 for cordova CLI to automagically to install an older version. It
> >>will
> >> > be a pain to get this implemented right, we would need to download all
> >> the
> >> > package.json for multiple versions of the plugin and pick the lowest
> >> common
> 

[GitHub] cordova-ios pull request: CB-9693 Fix www copy with spaces in proj...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-ios/pull/166


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-docs pull request: Implementing Proper Latest Docs Version

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-docs/pull/358


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-docs pull request: Adding Syntax Highlighting to Site

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-docs/pull/359


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [Android] 5.0.x release branch?

[Steven Gill]

so plugins that require cordova-android 5.0 + should definitely be adding
an engine tag specifying that.

We could look into some way for cordova-cli possibly fetching older
versions if cordova plugin add fails but I imagine this code being ugly and
easily breakable.

it would be nice to start moving engine tag type stuff out of plugin.xml
and into package.json. We probably want to update our tools to consume that
info from package.json instead of plugin.xml. Something we should make a
proposal for to see how it would look. Adding that info to searching would
be very beneficial. This is for a separate discussion (possibly f2f)





On Wed, Sep 23, 2015 at 2:19 PM, Joe Bowser  wrote:

> On Wed, Sep 23, 2015 at 2:05 PM, Frederico Galvão <
> frederico.gal...@pontoget.com.br> wrote:
>
> > Based on [1] I think we're overthinking here...
> >
> > I might have missed something, but as far as I understood it all, the
> only
> > thing preventing new plugin versions from working on older
> cordova-android
> > based projects is the POSSIBLE FACT that these projects will still
> > have android:targetSdkVersion="N < 23". It's not a sure bet, it's a
> > possibility. My project, for example, will already
> > have android:targetSdkVersion="23" when I upgrade to cordova-android 5.x
> > with all the plugins upgraded too, so even if I only upgraded the plugins
> > it would still work.
> >
> >
> If you only upgrade the plugins, it won't compile because the new plugins
> now call methods in Cordova 5.0.x to handle the permissions in
> Marshmellow.  We didn't remove any API calls, we just added new ones to
> deal with the API changes on Android to deal with the permissions system
> they're rolling out.  That's why this major version exists at all,
> otherwise you would be right, and this would be a non-issue.
>
>
> > It's common sense for android developers to bump the targetSdkVersion to
> > the latest once a new one comes out, the android APIs are always
> backwards
> > compatible, even if it means for the google team to code migration or
> > compatibility code (which they have always done afaik). If an app
> developer
> > is upgrading his plugins on an existing app, there is no obvious reason
> for
> > him not to also bump the targetSdkVersion. An app developer will always
> > want to support the largest and newest devices, it's a larger audience
> for
> > them anyway.
> >
>
> Upgrading to 5.0 bumps this automatically.
>
>
> > With that said, I don't think any of the mentioned complexity is needed
> > (package.json metadata, plugman version tryouts, engine tags in
> plugin.xml
> > or reflection). We just need to add hooks to the plugins that check the
> > targetSdkVersions on plugin_install, and warn the user about this if it's
> > bellow 23.
> >
> >
> It's needed for plugins that use permissions.  Most plugins aren't affected
> by this, such as plugins for ad networks.
>
> BTW: INTERNET permission isn't one that is prompted.  You can't revoke an
> app's ability to go online.  I think that's dumb, but whatever.
>
>
>
> > [1]
> > > They won't be compatible because Cordova-Android compiles against API
> 22,
> > and these plugins will require API 23 so that they can detect permissions
> > and support Marshmellow.
> >
> > 2015-09-23 15:33 GMT-03:00 Joe Bowser :
> >
> > > On Wed, Sep 23, 2015 at 11:30 AM, Joe Bowser 
> wrote:
> > >
> > > >
> > > > On Wed, Sep 23, 2015 at 11:22 AM, Homer, Tony 
> > > > wrote:
> > > >
> > > >> Joe-
> > > >>
> > > >> As far as I can tell, the API 23 calls are currently unguarded so
> > smores
> > > >> will only work on M Preview.
> > > >> I know your smores branch is a POC, but I was wondering about
> > backwards
> > > >> compatibility.
> > > >> Do you anticipate adding Build.VERSION.SDK_INT >=
> > Build.VERSION_CODES.M
> > > >> guard clauses for backwards compatibility?
> > > >>
> > > >>
> > > > This already exists in each of the plugins when they do the
> permissions
> > > > check, and smores works perfectly fine on Lollipop so far.  Right
> now,
> > if
> > > > you aren't running M, you don't do the permissions check, and you
> don't
> > > > call the methods.  I haven't tested it on earlier versions of
> Android,
> > > but
> > > > I expect it to work on Kitkat and Jellybean the same way.
> > > >
> > > >
> > > >
> > >
> > > And yes, we can probably create a utility method, that said, most
> plugins
> > > aren't directly affected by this, only the ones that require extra
> > > permissions.  It'd be good if we had an idea of what third party
> plugins
> > > people are actually using that would run afowl of this and see where
> they
> > > would fail.  But I already have more than enough work currently, and
> > > adopting other people's plugins is not something I want to get in the
> > habit
> > > of doing.
> > >
> > >
> > >
> > > > Tony
> > > >>
> > > >> On 9/23/15, 1:56 PM, "Joe Bowser"  wrote:
> > > >>

Re: [Android] 5.0.x release branch?

[Frederico Galvão]

>
> > Based on [1] I think we're overthinking here...
> >
> > I might have missed something, but as far as I understood it all, the
> only
> > thing preventing new plugin versions from working on older
> cordova-android
> > based projects is the POSSIBLE FACT that these projects will still
> > have android:targetSdkVersion="N < 23". It's not a sure bet, it's a
> > possibility. My project, for example, will already
> > have android:targetSdkVersion="23" when I upgrade to cordova-android 5.x
> > with all the plugins upgraded too, so even if I only upgraded the plugins
> > it would still work.
> >
> >
> If you only upgrade the plugins, it won't compile because the new plugins
> now call methods in Cordova 5.0.x to handle the permissions in
> Marshmellow.  We didn't remove any API calls, we just added new ones to
> deal with the API changes on Android to deal with the permissions system
> they're rolling out.  That's why this major version exists at all,
> otherwise you would be right, and this would be a non-issue.


That's why I mentioned [1], which you proved incomplete just now.

They won't be compatible because Cordova-Android compiles against API 22,
> and these plugins will require API 23 so that they can detect permissions
> and support Marshmellow.


The reason they won't be compatible is not only because the compilation
target, but also because the new plugins need new methods from
cordova-android@5.

I then take my post back, it was the product of misinformation. I also hope
we don't go the reflection way then :)

2015-09-23 18:36 GMT-03:00 Steven Gill :

> so plugins that require cordova-android 5.0 + should definitely be adding
> an engine tag specifying that.
>
> We could look into some way for cordova-cli possibly fetching older
> versions if cordova plugin add fails but I imagine this code being ugly and
> easily breakable.
>
> it would be nice to start moving engine tag type stuff out of plugin.xml
> and into package.json. We probably want to update our tools to consume that
> info from package.json instead of plugin.xml. Something we should make a
> proposal for to see how it would look. Adding that info to searching would
> be very beneficial. This is for a separate discussion (possibly f2f)
>
>
>
>
>
> On Wed, Sep 23, 2015 at 2:19 PM, Joe Bowser  wrote:
>
> > On Wed, Sep 23, 2015 at 2:05 PM, Frederico Galvão <
> > frederico.gal...@pontoget.com.br> wrote:
> >
> > > Based on [1] I think we're overthinking here...
> > >
> > > I might have missed something, but as far as I understood it all, the
> > only
> > > thing preventing new plugin versions from working on older
> > cordova-android
> > > based projects is the POSSIBLE FACT that these projects will still
> > > have android:targetSdkVersion="N < 23". It's not a sure bet, it's a
> > > possibility. My project, for example, will already
> > > have android:targetSdkVersion="23" when I upgrade to cordova-android
> 5.x
> > > with all the plugins upgraded too, so even if I only upgraded the
> plugins
> > > it would still work.
> > >
> > >
> > If you only upgrade the plugins, it won't compile because the new plugins
> > now call methods in Cordova 5.0.x to handle the permissions in
> > Marshmellow.  We didn't remove any API calls, we just added new ones to
> > deal with the API changes on Android to deal with the permissions system
> > they're rolling out.  That's why this major version exists at all,
> > otherwise you would be right, and this would be a non-issue.
> >
> >
> > > It's common sense for android developers to bump the targetSdkVersion
> to
> > > the latest once a new one comes out, the android APIs are always
> > backwards
> > > compatible, even if it means for the google team to code migration or
> > > compatibility code (which they have always done afaik). If an app
> > developer
> > > is upgrading his plugins on an existing app, there is no obvious reason
> > for
> > > him not to also bump the targetSdkVersion. An app developer will always
> > > want to support the largest and newest devices, it's a larger audience
> > for
> > > them anyway.
> > >
> >
> > Upgrading to 5.0 bumps this automatically.
> >
> >
> > > With that said, I don't think any of the mentioned complexity is needed
> > > (package.json metadata, plugman version tryouts, engine tags in
> > plugin.xml
> > > or reflection). We just need to add hooks to the plugins that check the
> > > targetSdkVersions on plugin_install, and warn the user about this if
> it's
> > > bellow 23.
> > >
> > >
> > It's needed for plugins that use permissions.  Most plugins aren't
> affected
> > by this, such as plugins for ad networks.
> >
> > BTW: INTERNET permission isn't one that is prompted.  You can't revoke an
> > app's ability to go online.  I think that's dumb, but whatever.
> >
> >
> >
> > > [1]
> > > > They won't be compatible because Cordova-Android compiles against API
> > 22,
> > > and these plugins will require API 23 so that they can 

[GitHub] cordova-docs pull request: Add Pacifica to showcase apps.

[dblotsky]

Github user dblotsky commented on the pull request:

https://github.com/apache/cordova-docs/pull/360#issuecomment-142712182
  
Merged! Feel free to close the PR and delete the branch.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [Android] 5.0.x release branch?

[Frederico Galvão]

Based on [1] I think we're overthinking here...

I might have missed something, but as far as I understood it all, the only
thing preventing new plugin versions from working on older cordova-android
based projects is the POSSIBLE FACT that these projects will still
have android:targetSdkVersion="N < 23". It's not a sure bet, it's a
possibility. My project, for example, will already
have android:targetSdkVersion="23" when I upgrade to cordova-android 5.x
with all the plugins upgraded too, so even if I only upgraded the plugins
it would still work.

It's common sense for android developers to bump the targetSdkVersion to
the latest once a new one comes out, the android APIs are always backwards
compatible, even if it means for the google team to code migration or
compatibility code (which they have always done afaik). If an app developer
is upgrading his plugins on an existing app, there is no obvious reason for
him not to also bump the targetSdkVersion. An app developer will always
want to support the largest and newest devices, it's a larger audience for
them anyway.

With that said, I don't think any of the mentioned complexity is needed
(package.json metadata, plugman version tryouts, engine tags in plugin.xml
or reflection). We just need to add hooks to the plugins that check the
targetSdkVersions on plugin_install, and warn the user about this if it's
bellow 23.

[1]
> They won't be compatible because Cordova-Android compiles against API 22,
and these plugins will require API 23 so that they can detect permissions
and support Marshmellow.

2015-09-23 15:33 GMT-03:00 Joe Bowser :

> On Wed, Sep 23, 2015 at 11:30 AM, Joe Bowser  wrote:
>
> >
> > On Wed, Sep 23, 2015 at 11:22 AM, Homer, Tony 
> > wrote:
> >
> >> Joe-
> >>
> >> As far as I can tell, the API 23 calls are currently unguarded so smores
> >> will only work on M Preview.
> >> I know your smores branch is a POC, but I was wondering about backwards
> >> compatibility.
> >> Do you anticipate adding Build.VERSION.SDK_INT >= Build.VERSION_CODES.M
> >> guard clauses for backwards compatibility?
> >>
> >>
> > This already exists in each of the plugins when they do the permissions
> > check, and smores works perfectly fine on Lollipop so far.  Right now, if
> > you aren't running M, you don't do the permissions check, and you don't
> > call the methods.  I haven't tested it on earlier versions of Android,
> but
> > I expect it to work on Kitkat and Jellybean the same way.
> >
> >
> >
>
> And yes, we can probably create a utility method, that said, most plugins
> aren't directly affected by this, only the ones that require extra
> permissions.  It'd be good if we had an idea of what third party plugins
> people are actually using that would run afowl of this and see where they
> would fail.  But I already have more than enough work currently, and
> adopting other people's plugins is not something I want to get in the habit
> of doing.
>
>
>
> > Tony
> >>
> >> On 9/23/15, 1:56 PM, "Joe Bowser"  wrote:
> >>
> >> >On Wed, Sep 23, 2015 at 9:36 AM, Carlos Santana 
> >> >wrote:
> >> >
> >> >> No need to major version change for the Plugins, the API of the
> didn't
> >> >> change.
> >> >> Web developer still uses the same JS API to use the plugin.
> >> >>
> >> >>
> >> >I would do a major version bump on Geolocation.  The API itself didn't
> >> >change but the behaviour certainly did.  On Marshmallow we have to add
> >> >this
> >> >extra shim that asks for permission, which means that there's now code
> >> >attached to Android Geolocation that didn't exist before.  All the
> other
> >> >plugins should still be fine.
> >> >
> >> >
> >> >> Yes I did some thinking around the plugin search website. I think is
> a
> >> >>good
> >> >> topic for the F2F.
> >> >> Now that IBM is using Cordova Plugin more heavily to package our
> mobile
> >> >> SDKs using Cordova Plugins, I think is beneficial to expose more info
> >> >>about
> >> >> the plugin including engine tags
> >> >>
> >> >> I would not go and build our own backend and have our own registry
> with
> >> >> cordova metadata.
> >> >>
> >> >> I think the solution is to put the metadata of plugin.xml into
> >> >> package.json. We can show fast results in main search, but then user
> >> can
> >> >> drill into the plugin details, and we can have a view with more
> >> >>information
> >> >> and allow the user to select a specific version like we have today in
> >> >>our
> >> >> plugin website search using the cordova registry.
> >> >>
> >> >> The website can fetch the package.json and it will have the
> information
> >> >>to
> >> >> display to the user.
> >> >>
> >> >> So what I think we need to do is document and automate the
> information
> >> >>from
> >> >> plugin.xml including engine tags into the package.json.
> >> >>
> >> >> Today we have some sort of duplicate information between the
> "cordova"
> >> >>and
> >> >> 

[GitHub] cordova-docs pull request: Add Sworkit to Cordova App Showcase

[gylippus]

Github user gylippus commented on the pull request:

https://github.com/apache/cordova-docs/pull/361#issuecomment-142718883
  
Thanks @dblotsky 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-docs pull request: Add Sworkit to Cordova App Showcase

[gylippus]

Github user gylippus closed the pull request at:

https://github.com/apache/cordova-docs/pull/361


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: Our development process, revisited

[Joe Bowser]

On Wed, Sep 23, 2015 at 1:32 PM, Steven Gill  wrote:

> If we had to rush a CVE, wouldn't it make sense to do that off an existing
> released branch (4.1.x)?
>
> I think the only valid point is we don't want master in a state where tests
> aren't passing. Until then, work on a branch. But if tests are passing, no
> harm moving it into master. Especially if you want to release android
> sooner rather than later. Having it in master will be just as effective in
> regards to having people test.
>
> I think the argument against long lived release branches is the potential
> of making merging more difficult down the road.
>
> coho does prepare-release-branch command right now but it can't quite
> handle the usecase you are suggesting because it branches off master and it
> will change the versions in master which you don't want.
>
> Why the hesitation to do 5.0.x work in master?
>

Because the Nexus 6P hasn't been released yet.


>
> -Steve
>
>
> On Wed, Sep 23, 2015 at 12:45 PM, Joe Bowser  wrote:
>
> > Hey
> >
> > So, once again, we're trying to do this 5.0.x thing.  And once again, I'm
> > finding that I want to create a long-lived 5.0.x branch because that's
> what
> > we should do for major releases.  This won't be as long lived as last
> time
> > (should be released in early October, before we do our off-site, because
> > supporting API 23 would be a good thing), but here's some questions.
> >
> > 1. What was the argument against long-lived release branches?
> > 2. Can we get a change in coho to allow for this practice.  It seems to
> > only support dumping all the things into master, which isn't the right
> > thing to do.
> >
> > I know that people wanted to be able to just do dev off master and
> release
> > off that, and that master probably should be able to pass all tests and
> be
> > in a releasable state, but in reality, we needed to have a release branch
> > for people to test out BEFORE we do an actual release, so I'm wondering
> > whether we should make the decision to branch, then move all dev to the
> > branch, then once we release, rebase that back on master.
> >
> > I really don't want to re-open this super long debate, but I also want to
> > get a release out and not screw up Android if we have to rush a CVE.
> What
> > do people think?
> >
> > Joe
> >
>

Re: Our development process, revisited

[Carlos Santana]

Call me dumb now.
So what if Nexus 6P is not out yet, let's work on master and keep it stable and 
use branches for features or not stable code. 

What is the harm of putting the new code for target API 23 on master while 
Nexus 6P is not out yet?


- Carlos
Sent from my iPhone

> On Sep 23, 2015, at 4:35 PM, Joe Bowser  wrote:
> 
>> On Wed, Sep 23, 2015 at 1:32 PM, Steven Gill  wrote:
>> 
>> If we had to rush a CVE, wouldn't it make sense to do that off an existing
>> released branch (4.1.x)?
>> 
>> I think the only valid point is we don't want master in a state where tests
>> aren't passing. Until then, work on a branch. But if tests are passing, no
>> harm moving it into master. Especially if you want to release android
>> sooner rather than later. Having it in master will be just as effective in
>> regards to having people test.
>> 
>> I think the argument against long lived release branches is the potential
>> of making merging more difficult down the road.
>> 
>> coho does prepare-release-branch command right now but it can't quite
>> handle the usecase you are suggesting because it branches off master and it
>> will change the versions in master which you don't want.
>> 
>> Why the hesitation to do 5.0.x work in master?
> 
> Because the Nexus 6P hasn't been released yet.
> 
> 
>> 
>> -Steve
>> 
>> 
>>> On Wed, Sep 23, 2015 at 12:45 PM, Joe Bowser  wrote:
>>> 
>>> Hey
>>> 
>>> So, once again, we're trying to do this 5.0.x thing.  And once again, I'm
>>> finding that I want to create a long-lived 5.0.x branch because that's
>> what
>>> we should do for major releases.  This won't be as long lived as last
>> time
>>> (should be released in early October, before we do our off-site, because
>>> supporting API 23 would be a good thing), but here's some questions.
>>> 
>>> 1. What was the argument against long-lived release branches?
>>> 2. Can we get a change in coho to allow for this practice.  It seems to
>>> only support dumping all the things into master, which isn't the right
>>> thing to do.
>>> 
>>> I know that people wanted to be able to just do dev off master and
>> release
>>> off that, and that master probably should be able to pass all tests and
>> be
>>> in a releasable state, but in reality, we needed to have a release branch
>>> for people to test out BEFORE we do an actual release, so I'm wondering
>>> whether we should make the decision to branch, then move all dev to the
>>> branch, then once we release, rebase that back on master.
>>> 
>>> I really don't want to re-open this super long debate, but I also want to
>>> get a release out and not screw up Android if we have to rush a CVE.
>> What
>>> do people think?
>>> 
>>> Joe
>> 

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

[GitHub] cordova-docs pull request: Add Sworkit to Cordova App Showcase

[dblotsky]

Github user dblotsky commented on the pull request:

https://github.com/apache/cordova-docs/pull/361#issuecomment-142716538
  
Merged! Please feel free to close the PR and delete the branch.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] cordova-docs pull request: Add Pacifica to showcase apps.

[drbeermann]

Github user drbeermann commented on the pull request:

https://github.com/apache/cordova-docs/pull/360#issuecomment-142758383
  
Awesome, thank you!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: [Proposal][iOS] Drop support for iOS 7

[Anis KADRI]

+1 to dropping iOS 7.0 support. One can't even download iOS 7.0 simulator
in XCode 7.0 anymore.

On Wed, Sep 23, 2015 at 8:43 AM Carlos Santana  wrote:

> Hi I like what I see in the Windows Platform repo README.md
> https://github.com/apache/cordova-windows#requirements
>
> They lis the Mobile OS that they support and the ones that still work but
> deprecated.
>
> I think it will be clear to have the same for the other platforms (i.e. ios
> and android)
>
> For iOS, we can say iOS7 deprecated, iOS8 and iOS9 supported
> For Android, we can say Android 2.3 (less than API 14) not longer
> supported, API 22 supported, when cordova-android@5 comes out then target
> API 23 supported.
>
> Then it's easier and more clear to determined what is the Mobile OS
> supported for that specific version of the platform release.
>
>
>
> On Mon, Sep 21, 2015 at 2:50 PM Raymond Camden 
> wrote:
>
> > +1. I read today that 50% of active devices are already on 9.
> >
> > On Mon, Sep 21, 2015 at 1:41 PM, Shazron  wrote:
> > > Yeah I'm thinking cordova-ios 4.x should have this change.
> > >
> > > On Mon, Sep 21, 2015 at 11:36 AM, Simon MacDonald
> > >  wrote:
> > >> +1
> > >>
> > >> I like the idea of not actively breaking iOS 7 devices but not
> actively
> > >> testing them. The last iPhone that is stuck on iOS 7 is the iPhone 4
> > which
> > >> is 4 years old at this point.
> > >>
> > >> Are you thinking Cordova iOS 4 to introduce thus change?
> > >>
> > >> Simon
> > >> On Sep 21, 2015 2:29 PM, "Shazron"  wrote:
> > >>
> > >>> We tend to have this discussion every year. We've typically supported
> > >>> the current iOS version and one version back. This would mean just
> > >>> supporting iOS 9 and 8.
> > >>>
> > >>> I propose to drop support for iOS 7.
> > >>>
> > >>> This doesn't mean Cordova won't run on an iOS 7 device, but this
> means
> > >>> we won't test whether Cordova or the plugins run on it (i.e. not
> crash
> > >>> if they use a newer API).
> > >>>
> > >>> There is only one change required: Increasing the minimum
> > >>> DEPLOYMENT_TARGET to 8.0 in the new project template/xcconfig.
> > >>>
> > >>>
> > >>> According to Apple, 52% of devices are using iOS 9 already, and 41%
> > >>> are on iOS 8. 8% of users are on earlier iOS versions. (Yeah the math
> > >>> adds up to 101%??)
> > >>> Source: https://developer.apple.com/support/app-store/
> > >>>
> > >>> -
> > >>> 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
> > >
> >
> >
> >
> > --
> >
> ===
> > Raymond Camden, Developer Advocate for MobileFirst at IBM
> >
> > Email : raymondcam...@gmail.com
> > Blog : www.raymondcamden.com
> > Twitter: raymondcamden
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>

Re: Cordova website redesign

[Anis KADRI]

Waw. It looks really really nice! Thanks so much for taking care of this.

On Wed, Sep 23, 2015 at 2:45 PM Shazron  wrote:

> Thank you for doing this, the site is great!
> The community will love this.
>
> On Wed, Sep 23, 2015 at 11:02 AM, Ryan J. Salva 
> wrote:
> > TLDR
> >
> > -- Feedback requested for a proposed Cordova website redesign at
> > http://cordova.apache.org/use-the-force-luke
> >
> > -- The redesign was influenced by interviews with 300+ mobile
> > developers. From these conversations, we identified six top level
> > goals:
> >
> > 1. Establish that Cordova is an active project relevant to developers
> > in 2016 (the future!)
> >
> > 2. Show the potential of hybrid apps by highlighting some rock
> star-quality apps
> >
> > 3. Demonstrate critical mass by sharing a diverse set of tools and
> > businesses that have “made a bet” on Cordova
> >
> > 4. Improve developer’s first experience with Cordova by adding quick
> > start instructions and explanatory text for key concepts (e.g.
> > plugins)
> >
> > 5. Increase community participation by raising the visibility of
> > public forums (e.g. Slack, StackOverflow, Twitter)
> >
> > 6. Maintain consistency with the current website (i.e. branding and
> > content parity)
> >
> >
> >  The long read 
> >
> > Grab a cup of coffee. This is a long one.
> >
> > As some of you may know, several committers from the Seattle area
> > (including Nikhil, Parashuram and I) have just completed a long series
> > of interviews with mobile developers. In the past three months, I’ve
> > personally interviewed over 100 developers. The team has collectively
> > interviewed closer to 300. We learned a lot and hope to share a
> > summary (with infographics!) of our insights soon. In the meantime, I
> > want to share one of the more poignant quotes from one interview. When
> > asked, “How can we make your job easier?”, one Cordova developer
> > responded:
> >
> >
> > “Take the stigma away from hybrid development. I can prove that it’s
> > the right tool for the job, but I have to prove it over-and-over
> > again. I wish that I didn’t have to have the same conversation every
> > time I want to use Cordova with a new manager or client.” -- Murali,
> > Cordova Developer
> >
> >
> > There are lots of ways to solve this problem, but one of the easier
> > and more visible ways is through Cordova’s front-door. The Cordova
> > website has served us well for the last 5+ years, but I believe a
> > redesign could help us address some pain points in the community. To
> > put it simply, we have a public perception problem.
> >
> >
> > “It’s hard to argue for Cordova when there are few examples of it
> > being successfully used.” -- Gary, Ionic Developer
> >
> >
> > Developers and architects are looking for examples of good development
> > to prove that high-quality, fast apps are possible. So, we thought it
> > might be good to highlight some rock star-quality apps on the home
> > page. Anyone can submit a PR to add their app so long as it appears in
> > a public store and uses Cordova. If the list of apps gets too long
> > (and it will), then we’ll randomize display. The same is true for a
> > list of tools and platforms that build on top of Cordova.
> >
> >
> > “There are so many layers to cross-platform development, it’s hard to
> > know how they all fit together. It’s even harder to know if you’re
> > missing a critical piece.” -- Mike, Cordova Developer
> >
> >
> > By itself, the website redesign won’t address this problem. We need
> > some good architectural docs that not only illustrate how Cordova
> > works, but also how it integrates with the larger ecosystem (e.g.
> > Crosswalk). However, we’re also hoping that by adding a little more
> > “hand-holding” on the site, we can help developers achieve success
> > faster. For example, we provide simple instructions for “Getting
> > Started” on the home page. And, on the Plugins page, we provide a
> > quick explanation of plugins’ role in Cordova development.
> >
> >
> > “It’s not clear where I can go for support.” -- Geoff, Cordova Developer
> >
> >
> > Okay…  none of us want to provide customer support for the whole
> > community, but I want to make it easy for people to find the
> > community. To that end, our goal was to integrate prominent pointers
> > to all the places where our community aggregates – e.g. Slack,
> > StackOverflow, JIRA and mailing list.
> >
> > Change for the sake of change is… well, for people with more time on
> > their hands than me, but this seems like the right time for a change
> > to the Cordova website. There’s a compelling developer need and little
> > risk in making the change.
> >
> > Barring any grievous concerns, I'd love to get the new site launched
> > ASAP. If we need to make small changes after launch, it will be easy
> > to iterate. If you see any bugs that need to be fixed, please file
> > them here:
> >
> > 

Re: Plugin docs generation

[Steven Gill]

I left some feedback on the PR

On Mon, Sep 21, 2015 at 3:28 AM, Sergey Shakhnazarov (Akvelon) <
v-ses...@microsoft.com> wrote:

> Hello dev-list,
>
> I have squashed plugin docs-gen issue into the PR[1], please take a look,
> I would appreciate your feedback!
> The solution uses jsdoc-to-markdown to generate md from JSDoc code
> comments with some customizations to enable source code links and ability
> to move large chunks (f.e. Quirks) to the template.
>
> Please let me know if you have any questions or considerations.
>
> [1]: https://github.com/cordova/cordova-discuss/pull/16
>
> Best regards,
> Sergey Shakhnazarov
>
> -Original Message-
> From: Sergey Shakhnazarov (Akvelon) [mailto:v-ses...@microsoft.com]
> Sent: Friday, September 4, 2015 11:56 PM
> To: dev@cordova.apache.org
> Subject: Plugin docs generation
>
> Hi guys,
>
> Please review a proposal on plugin documentation generation:
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fcordova%2fcordova-discuss%2fissues%2f15=01%7c01%7cv-seshak%40microsoft.com%7cecfd69748ea64d0641fd08d2b56b510e%7c72f988bf86f141af91ab2d7cd011db47%7c1=8M0Ab3UIpNxGCFEqEza3%2bEkQgb6Xr235sjeagi1FtWA%3d
>
> Best regards,
> Sergey Shakhnazarov
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> For additional commands, e-mail: dev-h...@cordova.apache.org
>
>

Re: Plugin docs generation

[Carlos Santana]

This is great!, left feedback on the PR

On Wed, Sep 23, 2015 at 8:11 PM Steven Gill  wrote:

> I left some feedback on the PR
>
> On Mon, Sep 21, 2015 at 3:28 AM, Sergey Shakhnazarov (Akvelon) <
> v-ses...@microsoft.com> wrote:
>
> > Hello dev-list,
> >
> > I have squashed plugin docs-gen issue into the PR[1], please take a look,
> > I would appreciate your feedback!
> > The solution uses jsdoc-to-markdown to generate md from JSDoc code
> > comments with some customizations to enable source code links and ability
> > to move large chunks (f.e. Quirks) to the template.
> >
> > Please let me know if you have any questions or considerations.
> >
> > [1]: https://github.com/cordova/cordova-discuss/pull/16
> >
> > Best regards,
> > Sergey Shakhnazarov
> >
> > -Original Message-
> > From: Sergey Shakhnazarov (Akvelon) [mailto:v-ses...@microsoft.com]
> > Sent: Friday, September 4, 2015 11:56 PM
> > To: dev@cordova.apache.org
> > Subject: Plugin docs generation
> >
> > Hi guys,
> >
> > Please review a proposal on plugin documentation generation:
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fcordova%2fcordova-discuss%2fissues%2f15=01%7c01%7cv-seshak%40microsoft.com%7cecfd69748ea64d0641fd08d2b56b510e%7c72f988bf86f141af91ab2d7cd011db47%7c1=8M0Ab3UIpNxGCFEqEza3%2bEkQgb6Xr235sjeagi1FtWA%3d
> >
> > Best regards,
> > Sergey Shakhnazarov
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > For additional commands, e-mail: dev-h...@cordova.apache.org
> >
> >
>