Re: [VOTE] 3.8.0 BlackBerry Release (take 2)

[Bryan Higgins]

Thanks Shaz! The post is live now.

On Mon, Sep 7, 2015 at 3:22 AM, Shazron <shaz...@gmail.com> wrote:

> Added you and merged.
>
> On Sat, Sep 5, 2015 at 2:11 PM, Bryan Higgins <br...@bryanhiggins.net>
> wrote:
>
> > I've published the artifacts, but no luck with the blog post.
> >
> > Could someone please add me to "Cordova" or merge my PR?
> > https://github.com/cordova/apache-blog-posts/pull/45
> >
> >
> > On Sat, Sep 5, 2015 at 7:01 AM, Bryan Higgins <br...@bryanhiggins.net>
> > wrote:
> >
> > > The vote has now closed. The results are:
> > >
> > > Positive Binding Votes:
> > >
> > > Bryan Higgins
> > > Steven Gill
> > > Carlos Santana
> > >
> > > Positive Non-Binding Votes:
> > > Tim Windsor
> > >
> > > The vote has passed.
> > >
> > > I will publish to dist/npm/blog.
> > >
> > > On Thu, Sep 3, 2015 at 2:01 PM, Carlos Santana <csantan...@gmail.com>
> > > wrote:
> > >
> > >> +1
> > >>
> > >> - verify signatures
> > >> - verify tags
> > >> - recreated archive and compare contents
> > >>
> > >>
> > >>
> > >> On Thu, Sep 3, 2015 at 1:52 PM Steven Gill <stevengil...@gmail.com>
> > >> wrote:
> > >>
> > >> > +1
> > >> >
> > >> > On Wed, Sep 2, 2015 at 2:39 PM, Tim Windsor <
> twind...@blackberry.com>
> > >> > wrote:
> > >> >
> > >> > > +1 (non-PMC member)
> > >> > >
> > >> > > Tested:
> > >> > > - new project creation, platform add and build to device.
> > >> > > - webworks-cli (3.6.0) new project creation, update to 3.8.0 and
> > >> deploy
> > >> > to
> > >> > > device
> > >> > > - new cordova project, add blackberry10 3.7.0 platfrom, update to
> > >> 3.8.0
> > >> > > and deploy to device
> > >> > > - build and run mobile-spec app
> > >> > >
> > >> > > Tim Windsor
> > >> > > Open Source Technical Lead – Devices
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > -Original Message-
> > >> > > From: Bryan Higgins [mailto:br...@bryanhiggins.net]
> > >> > > Sent: Wednesday, September 02, 2015 5:29 PM
> > >> > > To: dev@cordova.apache.org
> > >> > > Subject: [VOTE] 3.8.0 BlackBerry Release (take 2)
> > >> > >
> > >> > > Please review and vote on this 3.8.0 BlackBerry Release by
> replying
> > to
> > >> > > this email (and keep discussion on the DISCUSS thread)
> > >> > >
> > >> > > Release issue: https://issues.apache.org/jira/browse/CB-9576
> > >> > >
> > >> > > The archive has been published to dist/dev:
> > >> > > https://dist.apache.org/repos/dist/dev/cordova/CB-9576
> > >> > >
> > >> > > The package was published from its corresponding git tag:
> > >> > > 6790a1ed4b
> > >> > >
> > >> > > Note that you can test it out via:
> > >> > >
> > >> > > cordova platform add
> > >> > > https://github.com/apache/cordova-blackberry#3.8.0
> > >> > >
> > >> > > Blog post to review is here:
> > >> > >
> > >> > > https://github.com/cordova/apache-blog-posts/pull/45
> > >> > >
> > >> > > Upon a successful vote I will upload the archive to dist/, publish
> > it
> > >> to
> > >> > > NPM, and post the blog post.
> > >> > >
> > >> > > Voting guidelines:
> > >> > >
> > >> >
> > >>
> >
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
> > >> > >
> > >> > > Voting will go on for a minimum of 48 hours.
> > >> > >
> > >> > > I vote +1:
> > >> > > * Ran coho audit-license-headers over the relevant repos
> > >> > > * Ran coho check-license to ensure all dependencies and
> > >> subdependencies
> > >> > > have Apache-compatible licenses
> > >> > > * Tested project creation and device deployment
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>

Re: [VOTE] 3.8.0 BlackBerry Release (take 2)

[Bryan Higgins]

The vote has now closed. The results are:

Positive Binding Votes:

Bryan Higgins
Steven Gill
Carlos Santana

Positive Non-Binding Votes:
Tim Windsor

The vote has passed.

I will publish to dist/npm/blog.

On Thu, Sep 3, 2015 at 2:01 PM, Carlos Santana <csantan...@gmail.com> wrote:

> +1
>
> - verify signatures
> - verify tags
> - recreated archive and compare contents
>
>
>
> On Thu, Sep 3, 2015 at 1:52 PM Steven Gill <stevengil...@gmail.com> wrote:
>
> > +1
> >
> > On Wed, Sep 2, 2015 at 2:39 PM, Tim Windsor <twind...@blackberry.com>
> > wrote:
> >
> > > +1 (non-PMC member)
> > >
> > > Tested:
> > > - new project creation, platform add and build to device.
> > > - webworks-cli (3.6.0) new project creation, update to 3.8.0 and deploy
> > to
> > > device
> > > - new cordova project, add blackberry10 3.7.0 platfrom, update to 3.8.0
> > > and deploy to device
> > > - build and run mobile-spec app
> > >
> > > Tim Windsor
> > > Open Source Technical Lead – Devices
> > >
> > >
> > >
> > >
> > > -Original Message-
> > > From: Bryan Higgins [mailto:br...@bryanhiggins.net]
> > > Sent: Wednesday, September 02, 2015 5:29 PM
> > > To: dev@cordova.apache.org
> > > Subject: [VOTE] 3.8.0 BlackBerry Release (take 2)
> > >
> > > Please review and vote on this 3.8.0 BlackBerry Release by replying to
> > > this email (and keep discussion on the DISCUSS thread)
> > >
> > > Release issue: https://issues.apache.org/jira/browse/CB-9576
> > >
> > > The archive has been published to dist/dev:
> > > https://dist.apache.org/repos/dist/dev/cordova/CB-9576
> > >
> > > The package was published from its corresponding git tag:
> > > 6790a1ed4b
> > >
> > > Note that you can test it out via:
> > >
> > > cordova platform add
> > > https://github.com/apache/cordova-blackberry#3.8.0
> > >
> > > Blog post to review is here:
> > >
> > > https://github.com/cordova/apache-blog-posts/pull/45
> > >
> > > Upon a successful vote I will upload the archive to dist/, publish it
> to
> > > NPM, and post the blog post.
> > >
> > > Voting guidelines:
> > >
> >
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
> > >
> > > Voting will go on for a minimum of 48 hours.
> > >
> > > I vote +1:
> > > * Ran coho audit-license-headers over the relevant repos
> > > * Ran coho check-license to ensure all dependencies and subdependencies
> > > have Apache-compatible licenses
> > > * Tested project creation and device deployment
> > >
> >
>

Re: [VOTE] 3.8.0 BlackBerry Release (take 2)

[Bryan Higgins]

I've published the artifacts, but no luck with the blog post.

Could someone please add me to "Cordova" or merge my PR?
https://github.com/cordova/apache-blog-posts/pull/45


On Sat, Sep 5, 2015 at 7:01 AM, Bryan Higgins <br...@bryanhiggins.net>
wrote:

> The vote has now closed. The results are:
>
> Positive Binding Votes:
>
> Bryan Higgins
> Steven Gill
> Carlos Santana
>
> Positive Non-Binding Votes:
> Tim Windsor
>
> The vote has passed.
>
> I will publish to dist/npm/blog.
>
> On Thu, Sep 3, 2015 at 2:01 PM, Carlos Santana <csantan...@gmail.com>
> wrote:
>
>> +1
>>
>> - verify signatures
>> - verify tags
>> - recreated archive and compare contents
>>
>>
>>
>> On Thu, Sep 3, 2015 at 1:52 PM Steven Gill <stevengil...@gmail.com>
>> wrote:
>>
>> > +1
>> >
>> > On Wed, Sep 2, 2015 at 2:39 PM, Tim Windsor <twind...@blackberry.com>
>> > wrote:
>> >
>> > > +1 (non-PMC member)
>> > >
>> > > Tested:
>> > > - new project creation, platform add and build to device.
>> > > - webworks-cli (3.6.0) new project creation, update to 3.8.0 and
>> deploy
>> > to
>> > > device
>> > > - new cordova project, add blackberry10 3.7.0 platfrom, update to
>> 3.8.0
>> > > and deploy to device
>> > > - build and run mobile-spec app
>> > >
>> > > Tim Windsor
>> > > Open Source Technical Lead – Devices
>> > >
>> > >
>> > >
>> > >
>> > > -Original Message-
>> > > From: Bryan Higgins [mailto:br...@bryanhiggins.net]
>> > > Sent: Wednesday, September 02, 2015 5:29 PM
>> > > To: dev@cordova.apache.org
>> > > Subject: [VOTE] 3.8.0 BlackBerry Release (take 2)
>> > >
>> > > Please review and vote on this 3.8.0 BlackBerry Release by replying to
>> > > this email (and keep discussion on the DISCUSS thread)
>> > >
>> > > Release issue: https://issues.apache.org/jira/browse/CB-9576
>> > >
>> > > The archive has been published to dist/dev:
>> > > https://dist.apache.org/repos/dist/dev/cordova/CB-9576
>> > >
>> > > The package was published from its corresponding git tag:
>> > > 6790a1ed4b
>> > >
>> > > Note that you can test it out via:
>> > >
>> > > cordova platform add
>> > > https://github.com/apache/cordova-blackberry#3.8.0
>> > >
>> > > Blog post to review is here:
>> > >
>> > > https://github.com/cordova/apache-blog-posts/pull/45
>> > >
>> > > Upon a successful vote I will upload the archive to dist/, publish it
>> to
>> > > NPM, and post the blog post.
>> > >
>> > > Voting guidelines:
>> > >
>> >
>> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
>> > >
>> > > Voting will go on for a minimum of 48 hours.
>> > >
>> > > I vote +1:
>> > > * Ran coho audit-license-headers over the relevant repos
>> > > * Ran coho check-license to ensure all dependencies and
>> subdependencies
>> > > have Apache-compatible licenses
>> > > * Tested project creation and device deployment
>> > >
>> >
>>
>
>

[VOTE] 3.8.0 BlackBerry Release (take 2)

[Bryan Higgins]

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

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

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

The package was published from its corresponding git tag:
6790a1ed4b

Note that you can test it out via:

cordova platform add https://github.com/apache/cordova-blackberry#3.8.0

Blog post to review is here:

https://github.com/cordova/apache-blog-posts/pull/45

Upon a successful vote I will upload the archive to dist/, publish it to
NPM, and post the blog post.

Voting guidelines:
https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

Voting will go on for a minimum of 48 hours.

I vote +1:
* Ran coho audit-license-headers over the relevant repos
* Ran coho check-license to ensure all dependencies and subdependencies
have Apache-compatible licenses
* Tested project creation and device deployment

Re: [DISCUSS] Tools Release?

[Bryan Higgins]

BB vote thread is up. I will need a couple more PMC members to chime in.

Thanks,
Bryan

On Tue, Sep 1, 2015 at 3:55 PM, Steven Gill  wrote:

> I'm going to wait until blackberry gets released before releasing tools.
> Just leave it behind RC for a few more days because I pinned blackberry to
> the new version which is being voted on so we wouldn't have to pump out
> another vote just for it.
>
> -Steve
>
> On Mon, Aug 31, 2015 at 4:46 PM, Tim Barham 
> wrote:
>
> > Thanks Steve. And yeah, I'd done the testing - just wanted to verify the
> > archives :).
> >
> > -Original Message-
> > From: Steven Gill [mailto:stevengil...@gmail.com]
> > Sent: Tuesday, September 1, 2015 4:00 AM
> > To: dev@cordova.apache.org
> > Subject: RE: [DISCUSS] Tools Release?
> >
> > Hey Tim,
> >
> > You are correct. I forgot to run svn commit. Updated RC's are now there.
> >
> > You can also test using npm install -g cordova@rc
> >
> > On Aug 30, 2015 10:01 PM, "Tim Barham"  wrote:
> >
> > > Hey Steve - you mention version bumps for lib, cli and plugman, but
> that
> > > doesn't seem to be what's in dist/dev... There we have lib 5.3.0, cli
> > 5.3.0
> > > and plugman 1.01, but in the vote email you refer to lib 5.3.1, cli
> 5.3.1
> > > and plugman 1.0.2. Did you miss updating dist/dev?
> > >
> > > -Original Message-
> > > From: Steven Gill [mailto:stevengil...@gmail.com]
> > > Sent: Saturday, August 29, 2015 10:11 AM
> > > To: dev@cordova.apache.org
> > > Subject: Re: [DISCUSS] Tools Release?
> > >
> > > Ended up making a mistake with lib which made me have to bump patch
> > > versions for lib, cli, and plugman. ugh. Vote is up.
> > >
> > > On Fri, Aug 28, 2015 at 11:18 AM, Steven Gill 
> > > wrote:
> > >
> > > > Release issue:
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-9574=01%7c01%7cTBARHAM%40064d.mgd.microsoft.com%7c7c548018227b4e339f2008d2b0066f52%7c72f988bf86f141af91ab2d7cd011db47%7c1=uXAIHKcK0orjQpH5%2bt9Nnwb3XQWuAFVnqgKme8mJ5uQ%3d
> > > >
> > > > On Thu, Aug 27, 2015 at 11:53 PM, Nikhil Khandelwal <
> > > > nikhi...@microsoft.com> wrote:
> > > >
> > > >> I really just meant minor version bump instead of major. Sorry for
> the
> > > >> mix-up in terminology.
> > > >>
> > > >> -Nikhil
> > > >>
> > > >> -Original Message-
> > > >> From: Carlos Santana [mailto:csantan...@gmail.com]
> > > >> Sent: Thursday, August 27, 2015 11:07 PM
> > > >> To: dev@cordova.apache.org
> > > >> Subject: Re: [DISCUSS] Tools Release?
> > > >>
> > > >> That was my thinking no API breakage no major bump.
> > > >>
> > > >> Feature added minor bump
> > > >>
> > > >> - Carlos
> > > >> Sent from my iPhone
> > > >>
> > > >> > On Aug 28, 2015, at 1:47 AM, Steven Gill 
> > > >> wrote:
> > > >> >
> > > >> > It is interesting. Adding a new platform could be consideration
> for
> > a
> > > >> > major or minor. The platform (OSX) is having a major jump.
> > > >> >
> > > >> > According to semver, a major would be making a incompatible api
> > change
> > > >> > and a minor would be adding functionality in a
> backwards-compatible
> > > >> manner.
> > > >> >
> > > >> > We don't break anything by adding osx, so I'm leaning toward
> minor.
> > > >> >
> > > >> > -Steve
> > > >> >
> > > >> > On Thu, Aug 27, 2015 at 10:37 PM, Carlos Santana
> > > >> > 
> > > >> > wrote:
> > > >> >
> > > >> >> +1 minor release bump not major
> > > >> >>
> > > >> >> - Carlos
> > > >> >> Sent from my iPhone
> > > >> >>
> > > >> >>> On Aug 27, 2015, at 11:45 PM, Nikhil Khandelwal
> > > >> >>> 
> > > >> >> wrote:
> > > >> >>>
> > > >> >>> Also, there has been a browser release that we need to pin.
> > > >> >>>
> > > >> >>> -Nikhil
> > > >> >>>
> > > >> >>> -Original Message-
> > > >> >>> From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com]
> > > >> >>> Sent: Wednesday, August 26, 2015 6:21 PM
> > > >> >>> To: dev@cordova.apache.org
> > > >> >>> Subject: RE: [DISCUSS] Tools Release?
> > > >> >>>
> > > >> >>> +1. Not sure if it will be a patch release as it does ship new
> > > >> >>> +platforms
> > > >> >> along with it and it could be considered a major bump because of
> > > that.
> > > >> >>>
> > > >> >>> -Nikhil
> > > >> >>>
> > > >> >>> -Original Message-
> > > >> >>> From: Jesse [mailto:purplecabb...@gmail.com]
> > > >> >>> Sent: Wednesday, August 26, 2015 6:17 PM
> > > >> >>> To: dev@cordova.apache.org
> > > >> >>> Subject: Re: [DISCUSS] Tools Release?
> > > >> >>>
> > > >> >>> +1
> > > >> >>>
> > > >> >>>
> > > >> >>>
> > > >>  On Aug 26, 2015, at 6:14 PM, Carlos Santana <
> > csantan...@gmail.com>
> > > >> >> wrote:
> > > >> 
> > > >>  Yep makes sense to cut a release before that PR hits master
> > > >> > On Wed, Aug 26, 2015 at 9:11 PM Carlos Santana
> > > >> > 

Re: [VOTE] 3.8.0 BlackBerry Release

[Bryan Higgins]

Thanks Tim. I'll merge that PR and get a new RC ready.

Vote is cancelled.

On Tue, Sep 1, 2015 at 1:09 PM, Tim Windsor <twind...@blackberry.com> wrote:

> Sorry, I thought I was already to vote for release but I found an issue
> when updating projects.
>
> Pull request is in for the fix:
> https://github.com/apache/cordova-blackberry/pull/191
>
> Otherwise the RC seems good.
>
> Tested mobile spec on 3.7.0 and RC, new project creation, platform add of
> RC, and run on device.
> Tested update of default project on WebWorks (3.6.0) and 3.7.0 to RC
> (failure when doing Cordova run)
> Tested update with the patch in the pull request and these previous
> failures succeeded.
>
> Tim Windsor
> Open Source Technical Lead – Devices
>
>
>
>
>
> -Original Message-
> From: Bryan Higgins [mailto:br...@bryanhiggins.net]
> Sent: Monday, August 31, 2015 7:40 PM
> To: dev@cordova.apache.org
> Subject: [VOTE] 3.8.0 BlackBerry Release
>
> Please review and vote on this 3.8.0 BlackBerry Release by replying to
> this email (and keep discussion on the DISCUSS thread)
>
> Release issue: https://issues.apache.org/jira/browse/CB-9576
>
> The archive has been published to dist/dev:
> https://dist.apache.org/repos/dist/dev/cordova/CB-9576
>
> The package was published from its corresponding git tag:
> 3530eaa782
>
> Note that you can test it out via:
>
> cordova platform add
> https://github.com/apache/cordova-blackberry#3.8.0
>
> Blog post to review is here:
>
> https://github.com/cordova/apache-blog-posts/pull/45
>
> Upon a successful vote I will upload the archive to dist/, publish it to
> NPM, and post the blog post.
>
> Voting guidelines:
> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
>
> Voting will go on for a minimum of 48 hours.
>
> I vote +1:
> * Ran coho audit-license-headers over the relevant repos
> * Ran coho check-license to ensure all dependencies and subdependencies
> have Apache-compatible licenses
>

Re: [Discuss] BlackBerry Release

[Bryan Higgins]

I'm on it :)

On Mon, Aug 31, 2015 at 7:00 PM, Steven Gill <stevengil...@gmail.com> wrote:

> Lets get this vote thread started!
>
> On Mon, Aug 31, 2015 at 1:06 PM, Tim Windsor <twind...@blackberry.com>
> wrote:
>
> > I've tested the mobile-spec app on the previous version and the new one.
> > While there are issues, they appear to be the same from what I've seen.
> >
> > Tim Windsor
> > Open Source Technical Lead – Devices
> >
> >
> >
> >
> >
> > -Original Message-
> > From: Bryan Higgins [mailto:br...@bryanhiggins.net]
> > Sent: Saturday, August 29, 2015 11:34 AM
> > To: dev@cordova.apache.org
> > Subject: Re: [Discuss] BlackBerry Release
> >
> > I've uploaded the RC here:
> > https://dist.apache.org/repos/dist/dev/cordova/CB-9576/
> >
> > We'll need to test it before starting a VOTE thread (hopefully on
> Monday).
> >
> > On Wed, Aug 26, 2015 at 3:39 PM, Tim Windsor <twind...@blackberry.com>
> > wrote:
> >
> > > Tim here - I think the code is in good shape for release. I've tested
> > > with it in a few projects that have built successfully.
> > >
> > > I've got no more pull requests planned at this time.
> > >
> > > Tim Windsor
> > > Open Source Technical Lead - Devices
> > >
> > >
> > >
> > >
> > >
> > > -Original Message-
> > > From: Carlos Santana [mailto:csantan...@gmail.com]
> > > Sent: Wednesday, August 26, 2015 8:56 AM
> > > To: dev@cordova.apache.org
> > > Subject: Re: [Discuss] BlackBerry Release
> > >
> > > Brian nice to hear from you.
> > >
> > > I completely understand, I'm not 100% still waiting on finance
> > > division to see if they will approve the expense.
> > >
> > > - Carlos
> > > Sent from my iPhone
> > >
> > > > On Aug 26, 2015, at 8:31 AM, Bryan Higgins <br...@bryanhiggins.net>
> > > wrote:
> > > >
> > > > Steve - thanks! I'll let you know if I hit any roadblocks.
> > > >
> > > > Carlos - I wish I could justify the expense! It would have been
> > > > great to catch up with everyone but I'm working on non-Cordova
> > > > related projects these days.
> > > >
> > > > On Tue, Aug 25, 2015 at 4:24 PM, Carlos Santana
> > > > <csantan...@gmail.com>
> > > > wrote:
> > > >
> > > >> Hey Brian are you going to Face to Face Meetup on Oct?
> > > >>
> > > >> - Carlos
> > > >> Sent from my iPhone
> > > >>
> > > >>> On Aug 25, 2015, at 4:09 PM, Steven Gill <stevengil...@gmail.com>
> > > wrote:
> > > >>>
> > > >>> Sweet! Let me know if you have any questions for releasing!
> > > >>>
> > > >>> -Steve
> > > >>>
> > > >>> On Tue, Aug 25, 2015 at 12:58 PM, Carlos Santana
> > > >>> <csantan...@gmail.com>
> > > >>> wrote:
> > > >>>
> > > >>>> You are alive!!!
> > > >>>>
> > > >>>> I was afraid a truck hit you all guys :-)
> > > >>>>
> > > >>>> - Carlos
> > > >>>> Sent from my iPhone
> > > >>>>
> > > >>>>>> On Aug 25, 2015, at 3:24 PM, Bryan Higgins
> > > >>>>>> <br...@bryanhiggins.net>
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>> Hi all,
> > > >>>>>
> > > >>>>> It's been a while :)
> > > >>>>>
> > > >>>>> I'd like to do a maintenance release for BlackBerry this week.
> > > >>>>> Here is
> > > >>>> the
> > > >>>>> change log for anyone interested. Special thanks to Tim Windsor
> > > >>>>> for
> > > >>>> taking
> > > >>>>> on much of this work.
> > > >>>>>
> > > >>>>> -Bryan
> > > >>>>>
> > > >>>>> CB-8306 Fix parseUri to handle http://foo/bar?a...@b.com
> > > >>>>> CB-7807 Add BlackBerry10 platform to a project on any
> > > >>>>> workstation OS
> > > >>>>> CB-8417 moved platform specific js into platform
> > > >>>>> CB-8417 renamed platform_modules into cordova-js-src
> > > >>>>> CB-8899 stick to grunt-jasmine-node@0.2.1
> > > >>>>> CB-9072 Fix exception logging in packager.js
> > > >>>>> CB-9010 Adds check_reqs implementation
> > > >>>>> CB-8941 Adds support for subdomain whitelisting
> > > >>>>> CB-6768 Handle icons outside of www/.
> > > >>>>> CB-9009 include http://localhost:8472 in Content-Security-Policy
> > > >> header
> > > >>>>> CB-6768 Default Icon is now copied into platform_www.
> > > >>>>
> > > >>>> -
> > > >>>> --
> > > >>>> -- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > >>>> For additional commands, e-mail: dev-h...@cordova.apache.org
> > > >>
> > > >> ---
> > > >> -- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > >> For additional commands, e-mail: dev-h...@cordova.apache.org
> > > >>
> > > >>
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
> > > For additional commands, e-mail: dev-h...@cordova.apache.org
> > >
> > >
> >
>

[VOTE] 3.8.0 BlackBerry Release

[Bryan Higgins]

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

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

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

The package was published from its corresponding git tag:
3530eaa782

Note that you can test it out via:

cordova platform add https://github.com/apache/cordova-blackberry#3.8.0

Blog post to review is here:

https://github.com/cordova/apache-blog-posts/pull/45

Upon a successful vote I will upload the archive to dist/, publish it to
NPM, and post the blog post.

Voting guidelines:
https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

Voting will go on for a minimum of 48 hours.

I vote +1:
* Ran coho audit-license-headers over the relevant repos
* Ran coho check-license to ensure all dependencies and subdependencies
have Apache-compatible licenses

Re: [Discuss] BlackBerry Release

[Bryan Higgins]

I've uploaded the RC here:
https://dist.apache.org/repos/dist/dev/cordova/CB-9576/

We'll need to test it before starting a VOTE thread (hopefully on Monday).

On Wed, Aug 26, 2015 at 3:39 PM, Tim Windsor twind...@blackberry.com
wrote:

 Tim here - I think the code is in good shape for release. I've tested with
 it in a few projects that have built successfully.

 I've got no more pull requests planned at this time.

 Tim Windsor
 Open Source Technical Lead - Devices





 -Original Message-
 From: Carlos Santana [mailto:csantan...@gmail.com]
 Sent: Wednesday, August 26, 2015 8:56 AM
 To: dev@cordova.apache.org
 Subject: Re: [Discuss] BlackBerry Release

 Brian nice to hear from you.

 I completely understand, I'm not 100% still waiting on finance division to
 see if they will approve the expense.

 - Carlos
 Sent from my iPhone

  On Aug 26, 2015, at 8:31 AM, Bryan Higgins br...@bryanhiggins.net
 wrote:
 
  Steve - thanks! I'll let you know if I hit any roadblocks.
 
  Carlos - I wish I could justify the expense! It would have been great
  to catch up with everyone but I'm working on non-Cordova related
  projects these days.
 
  On Tue, Aug 25, 2015 at 4:24 PM, Carlos Santana csantan...@gmail.com
  wrote:
 
  Hey Brian are you going to Face to Face Meetup on Oct?
 
  - Carlos
  Sent from my iPhone
 
  On Aug 25, 2015, at 4:09 PM, Steven Gill stevengil...@gmail.com
 wrote:
 
  Sweet! Let me know if you have any questions for releasing!
 
  -Steve
 
  On Tue, Aug 25, 2015 at 12:58 PM, Carlos Santana
  csantan...@gmail.com
  wrote:
 
  You are alive!!!
 
  I was afraid a truck hit you all guys :-)
 
  - Carlos
  Sent from my iPhone
 
  On Aug 25, 2015, at 3:24 PM, Bryan Higgins
  br...@bryanhiggins.net
  wrote:
 
  Hi all,
 
  It's been a while :)
 
  I'd like to do a maintenance release for BlackBerry this week.
  Here is
  the
  change log for anyone interested. Special thanks to Tim Windsor
  for
  taking
  on much of this work.
 
  -Bryan
 
  CB-8306 Fix parseUri to handle http://foo/bar?a...@b.comwhatever
  CB-7807 Add BlackBerry10 platform to a project on any workstation
  OS
  CB-8417 moved platform specific js into platform
  CB-8417 renamed platform_modules into cordova-js-src
  CB-8899 stick to grunt-jasmine-node@0.2.1
  CB-9072 Fix exception logging in packager.js
  CB-9010 Adds check_reqs implementation
  CB-8941 Adds support for subdomain whitelisting
  CB-6768 Handle icons outside of www/.
  CB-9009 include http://localhost:8472 in Content-Security-Policy
  header
  CB-6768 Default Icon is now copied into platform_www.
 
  ---
  -- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org
 
 


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

Re: [Discuss] BlackBerry Release

[Bryan Higgins]

Steve - thanks! I'll let you know if I hit any roadblocks.

Carlos - I wish I could justify the expense! It would have been great to
catch up with everyone but I'm working on non-Cordova related projects
these days.

On Tue, Aug 25, 2015 at 4:24 PM, Carlos Santana csantan...@gmail.com
wrote:

 Hey Brian are you going to Face to Face Meetup on Oct?

 - Carlos
 Sent from my iPhone

  On Aug 25, 2015, at 4:09 PM, Steven Gill stevengil...@gmail.com wrote:
 
  Sweet! Let me know if you have any questions for releasing!
 
  -Steve
 
  On Tue, Aug 25, 2015 at 12:58 PM, Carlos Santana csantan...@gmail.com
  wrote:
 
  You are alive!!!
 
  I was afraid a truck hit you all guys :-)
 
  - Carlos
  Sent from my iPhone
 
  On Aug 25, 2015, at 3:24 PM, Bryan Higgins br...@bryanhiggins.net
  wrote:
 
  Hi all,
 
  It's been a while :)
 
  I'd like to do a maintenance release for BlackBerry this week. Here is
  the
  change log for anyone interested. Special thanks to Tim Windsor for
  taking
  on much of this work.
 
  -Bryan
 
  CB-8306 Fix parseUri to handle http://foo/bar?a...@b.comwhatever
  CB-7807 Add BlackBerry10 platform to a project on any workstation OS
  CB-8417 moved platform specific js into platform
  CB-8417 renamed platform_modules into cordova-js-src
  CB-8899 stick to grunt-jasmine-node@0.2.1
  CB-9072 Fix exception logging in packager.js
  CB-9010 Adds check_reqs implementation
  CB-8941 Adds support for subdomain whitelisting
  CB-6768 Handle icons outside of www/.
  CB-9009 include http://localhost:8472 in Content-Security-Policy
 header
  CB-6768 Default Icon is now copied into platform_www.
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
  For additional commands, e-mail: dev-h...@cordova.apache.org
 
 

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

[Discuss] BlackBerry Release

[Bryan Higgins]

Hi all,

It's been a while :)

I'd like to do a maintenance release for BlackBerry this week. Here is the
change log for anyone interested. Special thanks to Tim Windsor for taking
on much of this work.

-Bryan

CB-8306 Fix parseUri to handle http://foo/bar?a...@b.comwhatever
CB-7807 Add BlackBerry10 platform to a project on any workstation OS
CB-8417 moved platform specific js into platform
CB-8417 renamed platform_modules into cordova-js-src
CB-8899 stick to grunt-jasmine-node@0.2.1
CB-9072 Fix exception logging in packager.js
CB-9010 Adds check_reqs implementation
CB-8941 Adds support for subdomain whitelisting
CB-6768 Handle icons outside of www/.
CB-9009 include http://localhost:8472 in Content-Security-Policy header
CB-6768 Default Icon is now copied into platform_www.

Re: [Vote] 3.7.0 BlackBerry 10 Release

[Bryan Higgins]

The vote has now closed. The results are:

Positive Binding Votes: 3
Bryan Higgins
Josh Soref
Sergey Grebnov

Negative Binding Votes: 0

The vote has passed.

I will publish to dist and npm.

On Wed, Dec 24, 2014 at 4:04 PM, Sergey Grebnov (Akvelon) 
v-seg...@microsoft.com wrote:

 I vote +1:
 * verified platform could be added and built

 -Sergey
 -Original Message-
 From: Bryan Higgins [mailto:br...@bryanhiggins.net]
 Sent: Monday, December 22, 2014 10:46 PM
 To: dev@cordova.apache.org
 Subject: [Vote] 3.7.0 BlackBerry 10 Release

 Please review and vote on this 3.7.0 BlackBerry 10 Release.

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

 Repos ready to be released have been published to dist/dev

 The package was published from its corresponding git tag:
 cordova-blackberry: 3.7.0 (f7ad221)

 Voting guidelines:
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

 Voting will go on for a minimum of 48 hours.

 I vote +1:
 * Ran coho audit-license-headers over the relevant repos
 * Ran coho check-license to ensure all dependencies and subdependencies
 have Apache-compatible licenses
 * Ran automated and manual tests

[Vote] 3.7.0 BlackBerry 10 Release

[Bryan Higgins]

Please review and vote on this 3.7.0 BlackBerry 10 Release.

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

Repos ready to be released have been published to dist/dev

The package was published from its corresponding git tag:
cordova-blackberry: 3.7.0 (f7ad221)

Voting guidelines:
https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

Voting will go on for a minimum of 48 hours.

I vote +1:
* Ran coho audit-license-headers over the relevant repos
* Ran coho check-license to ensure all dependencies and subdependencies
have Apache-compatible licenses
* Ran automated and manual tests

Re: PhoneGap day

[Bryan Higgins]

I'll be there :)

On Mon, Oct 20, 2014 at 12:49 AM, Jesse purplecabb...@gmail.com wrote:

 James:

 PhoneGap day is in San Francisco this year.
 Details+tickets here: http://j.mp/PGDayUSA-Tix

 Sent from here

  On Oct 18, 2014, at 3:29 PM, James Litten insydneyja...@gmail.com
 wrote:
 
  Hello Jesse,
 
  Where is Phonegap day being held ?
 
 
 
  On Sat, Oct 18, 2014 at 12:08 PM, Jesse purplecabb...@gmail.com
 wrote:
 
  Who all is coming?
 
  I will be there for my first ever phonegap day. I've only been working
 with
  phonegap since 2008 ...
 
  Cheers,
   Jesse
 
 
  @purplecabbage
  risingj.com
 

Re: adding push notifications to core plugins

[Bryan Higgins]

+1 so I don't have to bug Jesse to merge my pull requests anymore ;)

On Thu, Oct 16, 2014 at 3:17 PM, Shazron shaz...@gmail.com wrote:

 +1 esp since we have an emerging standard now:
 http://www.w3.org/TR/2014/WD-push-api-20141007/

 On Thu, Oct 16, 2014 at 11:58 AM, Brian LeRoux b...@brian.io wrote:

  just was discussing w/ Shaz and Jesse…thoughts?
 

Re: cordova push plugin release

[Bryan Higgins]

Jesse - any chance you can merge this pull request? :)

https://github.com/phonegap-build/PushPlugin/pull/253

On Thu, Sep 18, 2014 at 3:56 PM, Jesse purplecabb...@gmail.com wrote:

 I have also recently published this one:

 com.phonegap.plugins.pushplugin@2.2.1

 With recently added support for wp8, and windows8 ( Thanks Sergey!)



 @purplecabbage
 risingj.com

 On Thu, Sep 18, 2014 at 11:25 AM, Carlos Santana csantan...@gmail.com
 wrote:

  I think is the aerogear push
 
  http://plugins.cordova.io/#/package/org.jboss.aerogear.cordova.push
 
  On Thu, Sep 18, 2014 at 1:38 PM, Parashuram Narasimhan (MS OPEN TECH) 
  panar...@microsoft.com wrote:
 
   Hi Erik,
  
   Where is this push plugin available ?
  
   -Original Message-
   From: Erik Jan de Wit [mailto:ede...@redhat.com]
   Sent: Tuesday, September 16, 2014 5:44 AM
   To: dev@cordova.apache.org
   Subject: Re: cordova push plugin release
  
   Ultimate goal is to enable swift as a language to create plugins with
  
   On 16 Sep,2014, at 11:41 , Erik Jan de Wit ede...@redhat.com wrote:
  
Hi all,
   
After testing we are happy to announce that the 1.0.1 version of the
   cordova push plugin has been released. Thanks to everyone for testing
 and
   making this release happen. The reason for this point release was an
  error
   in the android dependencies of the plugin making it unusable.
   
Happy coding,
  Erik Jan
  
  
 
 
  --
  Carlos Santana
  csantan...@gmail.com
 

Re: cordova push plugin release

[Bryan Higgins]

There are some apps pointing at the BlackBerry fork which have another
plugin installed that also uses the Android support library.

The jar file in the PGBuild repo has a bunch of classes stripped out of it
(FileProvider was needed in this case). I guess that was done to reduce APK
size rather than Google's recommended approach of using the ProGuard tool.

Anyway - if you want to cherry-pick the first commit in, I'll just open up
a separate pull request for this. Thanks!

On Fri, Sep 19, 2014 at 4:06 PM, Jesse purplecabb...@gmail.com wrote:

 Bryan - yes I can.  Why the changes to Android though?

 deleted:  src/android/com/plugin/android-support-v13.jar
 https://github.com/phonegap-build/PushPlugin/pull/253/files#diff-2
 plugin.xml
 + dependency id=android.support.v4 /



 @purplecabbage
 risingj.com

 On Fri, Sep 19, 2014 at 6:56 AM, Bryan Higgins br...@bryanhiggins.net
 wrote:

  Jesse - any chance you can merge this pull request? :)
 
  https://github.com/phonegap-build/PushPlugin/pull/253
 
  On Thu, Sep 18, 2014 at 3:56 PM, Jesse purplecabb...@gmail.com wrote:
 
   I have also recently published this one:
  
   com.phonegap.plugins.pushplugin@2.2.1
  
   With recently added support for wp8, and windows8 ( Thanks Sergey!)
  
  
  
   @purplecabbage
   risingj.com
  
   On Thu, Sep 18, 2014 at 11:25 AM, Carlos Santana csantan...@gmail.com
 
   wrote:
  
I think is the aerogear push
   
http://plugins.cordova.io/#/package/org.jboss.aerogear.cordova.push
   
On Thu, Sep 18, 2014 at 1:38 PM, Parashuram Narasimhan (MS OPEN
 TECH) 
panar...@microsoft.com wrote:
   
 Hi Erik,

 Where is this push plugin available ?

 -Original Message-
 From: Erik Jan de Wit [mailto:ede...@redhat.com]
 Sent: Tuesday, September 16, 2014 5:44 AM
 To: dev@cordova.apache.org
 Subject: Re: cordova push plugin release

 Ultimate goal is to enable swift as a language to create plugins
 with

 On 16 Sep,2014, at 11:41 , Erik Jan de Wit ede...@redhat.com
  wrote:

  Hi all,
 
  After testing we are happy to announce that the 1.0.1 version of
  the
 cordova push plugin has been released. Thanks to everyone for
 testing
   and
 making this release happen. The reason for this point release was
 an
error
 in the android dependencies of the plugin making it unusable.
 
  Happy coding,
Erik Jan


   
   
--
Carlos Santana
csantan...@gmail.com
   
  
 

Re: [Vote] 3.6.3 Cadence Release

[Bryan Higgins]

+1

- Verified signatures and hashes for cordova-blackberry10
- Ran mobile spec on bb10 device

On Mon, Sep 15, 2014 at 2:36 PM, Archana Naik naik.arch...@gmail.com
wrote:

 +1 for me. Lets get this going.

 Archana

 On Fri, Sep 12, 2014 at 3:04 PM, Marcel Kinard cmarc...@gmail.com wrote:

  Please review and vote on this 3.6.3 Cadence Release.
 
  This 3.6.3 version is another attempt to publish 3.6.0 into the
 write-once
  npm registry after having issues during the publish step. 3.6.1 passed
 vote
  and was published to dist.a.o, but was not successful in getting
 published
  to npm. So this is another respin for the purpose of npm.
 
  Release issue: https://issues.apache.org/jira/browse/CB-7383
 
  Repos ready to be released have been published to dist/dev:
  https://dist.apache.org/repos/dist/dev/cordova/CB-7383
 
  The packages were published from their corresponding git tags:
  cordova-android: 3.6.3 (e2e38ad2b4)
  cordova-ios: 3.6.3 (5cee36c671)
  cordova-blackberry: 3.6.3 (f510800026)
  cordova-windows: 3.6.3 (2aa00365d4)
  cordova-wp8: 3.6.3 (95b01b1526)
  cordova-firefoxos: 3.6.3 (cba43a24ad)
  cordova-ubuntu: 3.6.3 (f5e1e80103)
  cordova-amazon-fireos: 3.6.3 (4645a45717)
  cordova-mobile-spec: 3.6.3 (3fba3d8ba0)
  cordova-app-hello-world: 3.6.3 (bab6ae893e)
 
  cordova-lib: 0.21.11 (5410fb437e)
  cordova-plugman: 0.22.8 (228002b0a2)
  cordova-cli: 3.6.3-0.2.11 (78d97448db)
 
  Upon a successful vote I will upload the archives to dist/, publish them
  to NPM, and post the corresponding blog post.
 
  Voting guidelines:
 
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
 
  Voting will go on for a minimum of 72 hours.
 
  I vote +1:
* it was created off the 3.6.x branches (or for the tools, an
 equivalent
  branch I created)
* it contains only a version bump over the previously-published 3.6.1
* ran coho verify-archive on all assets

Re: [Vote] 3.6.1 Cadence Release 3rd attempt

[Bryan Higgins]

err.. wrong thread :)

On Mon, Sep 15, 2014 at 3:55 PM, Bryan Higgins br...@bryanhiggins.net
wrote:

 +1

 - Verified signatures and hashes for cordova-blackberry10
 - Ran mobile spec on bb10 device

 On Mon, Sep 15, 2014 at 3:49 PM, Marcel Kinard cmarc...@gmail.com wrote:

 Given that the 72-hour mark will be reached within ~2 hours of now, don't
 worry about it. However, we still need at least one more +1 vote.

 On Sep 15, 2014, at 3:10 PM, Parashuram Narasimhan (MS OPEN TECH) 
 panar...@microsoft.com wrote:

  I looked at the voting process and it seems to say that the 72 hour
 window is a recommendation. Given that we have all verified the code
 multiple times and the community agrees that this is only a version bump,
 can we close the vote if we have 3 +1 votes ?

Re: [DISCUSS] Plugins Release

[Bryan Higgins]

The latest test runner does not work properly on BB10.

The tests continue infinitely (thousands of specs so far) and the output
slowly transitions from green to red.

I'll revert to an older version to test this release.

On Thu, Sep 11, 2014 at 1:42 PM, Sergey Grebnov (Akvelon) 
v-seg...@microsoft.com wrote:

 Could someone also review/merge the following PRs. Thanks in advance!

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

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

 https://github.com/apache/cordova-plugin-media-capture/pull/25
 https://github.com/apache/cordova-plugin-media-capture/pull/26

 https://github.com/apache/cordova-plugin-inappbrowser/pull/53

 -Sergey
 -Original Message-
 From: iclell...@google.com [mailto:iclell...@google.com] On Behalf Of Ian
 Clelland
 Sent: Thursday, September 11, 2014 9:35 PM
 To: dev@cordova.apache.org
 Subject: Re: [DISCUSS] Plugins Release

 I've seen the same thing with the new test runner.. it appears that the
 framework itself is rather fragile, and certain things, like calling done()
 twice within a test, will cause the whole test runner to go wonky.

 The file tests did this a couple of weeks ago, and I resolved it with
 CB-7431; I was running into it again this morning with the Contacts tests
 on Android, but the CB-7532 fix seems to have helped that.

 On Thu, Sep 11, 2014 at 1:22 PM, Archana Naik naik.arch...@gmail.com
 wrote:

  I am not sure if they are blockers. Mostly not. I am seeing about 12
  failures. spec 83, 84, 100,104,105,106108,110,113,114116,125,126127,128.
  I am also seeing weird thing about mobilespec reporting the failures.
  It reports each failure twice and runs the whole autotests twice. On
  top window i see finished in 50.0003s finished in 14.209s twice.
  Ofcourse second run reports almost double the failures coz it adds
  from previous run.
 
  As far as plugin release goes, i think we will need sometime in
  debugging these failures as well as mobilespec reporting bugs. I
  suppose we can go ahead with release and I will fix in parallel in
  master branch of file plugin.
  sounds good?
 
  Archana
 
  On Thu, Sep 11, 2014 at 10:07 AM, Martin Gonzalez 
  martin.c.glez.g...@gmail.com wrote:
 
   Hi Archana, which specs or what kind of failures are you getting
   over amazon-fireOs? is there any Jira Item related to that?
  
   2014-09-11 12:02 GMT-05:00 Marcel Kinard cmarc...@gmail.com:
  
Archana, do you think these are a blocker? If so, what would be
your
  time
estimate to get them fixed?
   
On Sep 11, 2014, at 12:00 PM, Archana Naik
naik.arch...@gmail.com
   wrote:
   
 With latest tests in plugins, I am seeing many failures on
   amazon-fireos
 esp in file tests. I would like to fix those if possible.
   
   
  
  
   --
   Regards,
   Martin Gonzalez
  
 

Re: [Vote] 3.6.1 Cadence Release 3rd attempt

[Bryan Higgins]

My inbox is getting flooded with reports of this issue:

npm http 200
https://registry.npmjs.org/cordova-blackberry10/-/cordova-blackberry10-3.6.1.tgz
Unable to fetch platform blackberry10: Error: shasum check failed for
/var/folders/dk/f9mzz67s72s0lzsv2b92ccwmgn/T/npm-28823-kUnITCqE/1410474423022-0.06607100926339626/tmp.tgz
Expected: 768267141f7716a3745073227b82ee654bea3371
Actual:   a3e007d3730d20b9711f004fb2da9a3528d1175c

It appears to affect all platforms.

Anything I can do to help? Can we point latest to 3.5 until this is
resolved?

On Thu, Sep 11, 2014 at 4:09 PM, Marcel Kinard cmarc...@gmail.com wrote:

 The vote has now closed. The results are:

 Positive Binding Votes: 4

 Marcel Kinard
 Archana Naik
 Sergey Grebnov
 Bryan Higgins

 Negative Binding Votes: 0

 The vote has passed.

 On Sep 8, 2014, at 3:40 PM, Marcel Kinard cmarc...@gmail.com wrote:

  Please review and vote on this 3.6.1 Cadence Release.
 
  (This includes fixes to cordova-lib to reference the 3.6.1 platforms.)
 
  Release issue: https://issues.apache.org/jira/browse/CB-7383
 
  Repos ready to be released have been published to dist/dev:
  https://dist.apache.org/repos/dist/dev/cordova/CB-7383
 
  The packages were published from their corresponding git tags:
 
 cordova-android: 3.6.1 (caa82b2f26)
 cordova-ios: 3.6.1 (2d8167fb46)
 cordova-blackberry: 3.6.1 (87d281354f)
 cordova-wp8: 3.6.1 (79546dcec6)
 cordova-windows: 3.6.1 (815f4bcde7)
 cordova-firefoxos: 3.6.1 (fcd5f68318)
 cordova-ubuntu: 3.6.1 (a03dee5bdb)
 cordova-amazon-fireos: 3.6.1 (48c7352451)
 
 cordova-mobile-spec: 3.6.1 (09baccdd57)
 cordova-app-hello-world: 3.6.1 (ff1fbfd574)
 
 cordova-lib: 0.21.10 (bc04dfb1f0)
 cordova-plugman: 0.22.7 (df6703bcae)
 cordova-cli: 3.6.1-0.2.10 (4c1c8c398e)
 
  Upon a successful vote I will upload the archives to dist/, publish them
 to NPM, and post the corresponding blog post.
 
  These rc's have NOT been published to npm.
 
  Voting guidelines:
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
 
  Voting will go on for a minimum of 72 hours.
 
  I do suggest a good sanity test, since the scripts didn't always work
 thus there was a good deal of manual work involved.
 
  I vote +1:
  * Small delta over 3.6.0 rc
  * Ran coho verify-archive over the relevant repos
  * Checked that continuous build was green when repos were tagged
  * Ran coho verify-tags over the relevant repos
  * Compared the contents of the tarballs to a git checkout
  * Ran mobile-spec automated tests with released plugins on Android: 2
 failures (filetransfer.spec.18, filetransfer.spec.19)
  * Ran mobile-spec automated tests with master version of plugins on
 Android: no failures
  * Ran Android native tests: no failures
 

Re: [Vote] 3.6.1 Cadence Release 3rd attempt

[Bryan Higgins]

I've pointed latest back to 3.5.0-0.2.7 for now.

On Thu, Sep 11, 2014 at 6:29 PM, Bryan Higgins br...@bryanhiggins.net
wrote:

 My inbox is getting flooded with reports of this issue:

 npm http 200
 https://registry.npmjs.org/cordova-blackberry10/-/cordova-blackberry10-3.6.1.tgz
 Unable to fetch platform blackberry10: Error: shasum check failed for
 /var/folders/dk/f9mzz67s72s0lzsv2b92ccwmgn/T/npm-28823-kUnITCqE/1410474423022-0.06607100926339626/tmp.tgz
 Expected: 768267141f7716a3745073227b82ee654bea3371
 Actual:   a3e007d3730d20b9711f004fb2da9a3528d1175c

 It appears to affect all platforms.

 Anything I can do to help? Can we point latest to 3.5 until this is
 resolved?

 On Thu, Sep 11, 2014 at 4:09 PM, Marcel Kinard cmarc...@gmail.com wrote:

 The vote has now closed. The results are:

 Positive Binding Votes: 4

 Marcel Kinard
 Archana Naik
 Sergey Grebnov
 Bryan Higgins

 Negative Binding Votes: 0

 The vote has passed.

 On Sep 8, 2014, at 3:40 PM, Marcel Kinard cmarc...@gmail.com wrote:

  Please review and vote on this 3.6.1 Cadence Release.
 
  (This includes fixes to cordova-lib to reference the 3.6.1 platforms.)
 
  Release issue: https://issues.apache.org/jira/browse/CB-7383
 
  Repos ready to be released have been published to dist/dev:
  https://dist.apache.org/repos/dist/dev/cordova/CB-7383
 
  The packages were published from their corresponding git tags:
 
 cordova-android: 3.6.1 (caa82b2f26)
 cordova-ios: 3.6.1 (2d8167fb46)
 cordova-blackberry: 3.6.1 (87d281354f)
 cordova-wp8: 3.6.1 (79546dcec6)
 cordova-windows: 3.6.1 (815f4bcde7)
 cordova-firefoxos: 3.6.1 (fcd5f68318)
 cordova-ubuntu: 3.6.1 (a03dee5bdb)
 cordova-amazon-fireos: 3.6.1 (48c7352451)
 
 cordova-mobile-spec: 3.6.1 (09baccdd57)
 cordova-app-hello-world: 3.6.1 (ff1fbfd574)
 
 cordova-lib: 0.21.10 (bc04dfb1f0)
 cordova-plugman: 0.22.7 (df6703bcae)
 cordova-cli: 3.6.1-0.2.10 (4c1c8c398e)
 
  Upon a successful vote I will upload the archives to dist/, publish
 them to NPM, and post the corresponding blog post.
 
  These rc's have NOT been published to npm.
 
  Voting guidelines:
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
 
  Voting will go on for a minimum of 72 hours.
 
  I do suggest a good sanity test, since the scripts didn't always work
 thus there was a good deal of manual work involved.
 
  I vote +1:
  * Small delta over 3.6.0 rc
  * Ran coho verify-archive over the relevant repos
  * Checked that continuous build was green when repos were tagged
  * Ran coho verify-tags over the relevant repos
  * Compared the contents of the tarballs to a git checkout
  * Ran mobile-spec automated tests with released plugins on Android: 2
 failures (filetransfer.spec.18, filetransfer.spec.19)
  * Ran mobile-spec automated tests with master version of plugins on
 Android: no failures
  * Ran Android native tests: no failures
 

Re: [Vote] 3.6.1 Cadence Release 3rd attempt

[Bryan Higgins]

+1

- Verified signatures and hashes for cordova-blackberry10
- Ran mobile spec

On Tue, Sep 9, 2014 at 9:43 PM, Andrew Grieve agri...@chromium.org wrote:

 Updated the release post to trim down the Android section.

 On Mon, Sep 8, 2014 at 9:27 PM, Marcel Kinard cmarc...@gmail.com wrote:
  And here is the draft blog post:
 
 
 https://github.com/cordova/apache-blog-posts/blob/master/2014-09-08-cordova-361.md
 
  Please add highlights for your platform. Thanks!
 
  Begin forwarded message:
 
  From: Marcel Kinard cmarc...@gmail.com
  Subject: [Vote] 3.6.1 Cadence Release 3rd attempt
  Date: September 8, 2014 at 3:40:19 PM EDT
  To: dev@cordova.apache.org
 
  Please review and vote on this 3.6.1 Cadence Release.
 
  (This includes fixes to cordova-lib to reference the 3.6.1 platforms.)
 
  Release issue: https://issues.apache.org/jira/browse/CB-7383
 
  Repos ready to be released have been published to dist/dev:
  https://dist.apache.org/repos/dist/dev/cordova/CB-7383
 
  The packages were published from their corresponding git tags:
 
 cordova-android: 3.6.1 (caa82b2f26)
 cordova-ios: 3.6.1 (2d8167fb46)
 cordova-blackberry: 3.6.1 (87d281354f)
 cordova-wp8: 3.6.1 (79546dcec6)
 cordova-windows: 3.6.1 (815f4bcde7)
 cordova-firefoxos: 3.6.1 (fcd5f68318)
 cordova-ubuntu: 3.6.1 (a03dee5bdb)
 cordova-amazon-fireos: 3.6.1 (48c7352451)
 
 cordova-mobile-spec: 3.6.1 (09baccdd57)
 cordova-app-hello-world: 3.6.1 (ff1fbfd574)
 
 cordova-lib: 0.21.10 (bc04dfb1f0)
 cordova-plugman: 0.22.7 (df6703bcae)
 cordova-cli: 3.6.1-0.2.10 (4c1c8c398e)
 
  Upon a successful vote I will upload the archives to dist/, publish
 them to NPM, and post the corresponding blog post.
 
  These rc's have NOT been published to npm.
 
  Voting guidelines:
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
 
  Voting will go on for a minimum of 72 hours.
 
  I do suggest a good sanity test, since the scripts didn't always work
 thus there was a good deal of manual work involved.
 
  I vote +1:
  * Small delta over 3.6.0 rc
  * Ran coho verify-archive over the relevant repos
  * Checked that continuous build was green when repos were tagged
  * Ran coho verify-tags over the relevant repos
  * Compared the contents of the tarballs to a git checkout
  * Ran mobile-spec automated tests with released plugins on Android: 2
 failures (filetransfer.spec.18, filetransfer.spec.19)
  * Ran mobile-spec automated tests with master version of plugins on
 Android: no failures
  * Ran Android native tests: no failures
 
 

Re: [Vote] 3.6.0 Cadence Release

[Bryan Higgins]

+1

- Verified signatures and hashes for cordova-blackberry
- Verified sha1 match tag 3.6.0
- Ran mobile spec on various BB10 devices and OS versions

Steve - I added you as an owner for cordova-blackberry10 on npm. The
cordova-blackberry package should probably be unpublished.


On Tue, Sep 2, 2014 at 1:15 AM, Archana Naik naik.arch...@gmail.com wrote:

 vote +1
 Verified amazon-fireos bundle, signatures and hashes.

 When are we planning to publish it to npm?


 On Mon, Sep 1, 2014 at 2:40 PM, Sergey Grebnov (Akvelon) 
 v-seg...@microsoft.com wrote:

  I vote +1:
  * Verified signatures and hashes for cordova-cli, cordova-lib,
  cordova-plugman, cordova-windows, cordova-wp8
  * Verified sha1s match tags for cordova-cli, cordova-lib,
 cordova-plugman,
  cordova-windows, cordova-wp8
  * Run Medic tests for Windows and Windows Phone 8
  * Tested Android build on Windows
  * Tested Windows platform manually
  building and running app with VS2012 (msbuild 4.0)/VS2013(msbuild
 12.0)
  -win and -phone switches
  support of target platform settings (config.xml)
  support of custom icons and splash screen images
 
  Thx!
  Sergey
  -Original Message-
  From: Steven Gill [mailto:stevengil...@gmail.com]
  Sent: Saturday, August 30, 2014 5:35 AM
  To: dev@cordova.apache.org
  Subject: [Vote] 3.6.0 Cadence Release
 
  Please review and vote on this 3.6.0 Cadence Release.
 
  Release issue: https://issues.apache.org/jira/browse/CB-7383
 
  Repos ready to be released have been published to
  dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-7383
 
  The packages were published from their corresponding git tags:
  cordova-android: 3.6.0 (014327c59a)
  cordova-ios: 3.6.0 (3a92b2dbf0)
  cordova-blackberry: 3.6.0 (ed435bfc9e)
  cordova-windows: 3.6.0 (cdb292f4a3)
  cordova-wp8: 3.6.0 (a879f5258b)
  cordova-firefoxos: 3.6.0 (9ab176f855)
 
  cordova-ubuntu: 3.6.0 (bff472e4c2)
  cordova-amazon-fireos: 3.6.0 (4e94c6d198)
  cordova-js: 3.6.0 (906b34c0a4)
  cordova-mobile-spec: 3.6.0 (27053f7dd8)
  cordova-app-hello-world: 3.6.0 (65a2171a19)
 
  cordova-cli: 3.6.0-0.2.8 (01cb09f2d1)
  cordova-lib: 0.21.8 (14670ec9b5)
  cordova-plugman: 0.22.5 (29488fce7e)
 
 
  Upon a successful vote I will upload the archives to dist/, publish them
  to NPM, and post the corresponding blog post.
 
  Voting guidelines:
 
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
 
  Voting will go on for a minimum of 72 hours.
 
  I vote +1:
  * Ran coho audit-license-headers over the relevant repos
  * Used `license-checker` to ensure all dependencies have
 Apache-compatible
  licenses
  * Ensured continuous build was green when repos were tagged
 

Re: [Discuss] 3.6.0 Release

[Bryan Higgins]

BB10 should be good to go now.

I published cordova-blackberry10 as a package [1]. We had already updated
the name in package.json due to the strict name checking in CLI, so this
had to be done anyway.

Adding all packages to bundledDependencies works around the 'npm install'
problem [2].

[1] https://www.npmjs.org/package/cordova-blackberry10

[2]
https://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=commit;h=8f9248654791f820490919a876d06bba591f6f6c




On Tue, Aug 26, 2014 at 3:23 PM, Parashuram Narasimhan (MS OPEN TECH) 
panar...@microsoft.com wrote:

 We found a few issues with Windows Phone 8.1 (whitelist does not allow
 HTTP) that Sergey discussed and is fixing.

 -Original Message-
 From: Marcel Kinard [mailto:cmarc...@gmail.com]
 Sent: Tuesday, August 26, 2014 11:54 AM
 To: dev@cordova.apache.org
 Subject: Re: [Discuss] 3.6.0 Release

 I'm running mobile-spec (plugins + non-plugins + automatic + manual +
 platforms) with master on Android and finding a few failing tests, but they
 are getting fixed. With an impending 3.6.0 release soon, I would assume
 many others are doing the same. But perhaps that's not a good assumption.

 On Aug 8, 2014, at 2:11 PM, Steven Gill stevengil...@gmail.com wrote:

  How does everyone feel about me starting the release process next
  Tuesday, August 12, 2014?
 
  Will your platform be ready?

Re: WebView Promise and W3C standards

[Bryan Higgins]

BB10 does have a native secure element API. I may be able to dig up some
code which bridges this to JavaScript.


On Thu, Aug 14, 2014 at 7:41 AM, Axel Nennker ignisvul...@gmail.com wrote:

 I created https://issues.apache.org/jira/browse/CB-7310 to track this.


 2014-08-13 22:57 GMT+02:00 Axel Nennker ignisvul...@gmail.com:

  Good to know. Thanks.
   Am 13.08.2014 20:56 schrieb Josh Soref jso...@blackberry.com:
 
  Axel Nennker wrote:
  I am interested to implement the secure element API.
  Mozilla is currently implementing it with our help for FFOS but I want
 it
  for Android too. Blackberry shouldn't be that difficult using JSR177.
 
  BlackBerry classic (which is built around Java) isn't supported by
 Cordova
  and hasn't been for a few releases.
  BlackBerry 10 is built around QNX.
 
  I'm not making a statement about implementability re BB10 (just that
 Java
  is irrelevant),
 
 
 https://github.com/blackberry/Cascades-Community-Samples/tree/master/NfcToo
  l
 
  Is probably where someone would go to start...
 
 

Re: [VOTE] Plugins Release

[Bryan Higgins]

+1

- Confirmed signatures and hashes
- Verified sha1s against tags
- Ran mobile spec on BlackBerry 10


On Thu, Aug 7, 2014 at 3:53 PM, Andrew Grieve agri...@chromium.org wrote:

 +1

 * Confirmed sigs  hashes with `coho verify-archive`
 * Verified sha1s match tags with `coho verify-tags`



 On Thu, Aug 7, 2014 at 10:38 AM, Ian Clelland iclell...@chromium.org
 wrote:

  +1
 
  * Verified all archives
  * Verified that the tags are correct, and point to the hashes listed
  * Verified contents of archives against public repositories at the listed
  hashes
  * Ran mobile-spec on iOS (3.5.0 and master)
  * Ran mobile-spec on Android (3.5.1, 4.0.x and master)
 
 
  Note: Three plugins did not work for me initially with cordova-ios
  3.6.0-dev: Camera, Device-Orientation and Geolocation, since the
  CoreLocation framework has been removed from cordova-ios, and, for some
  reason, plugman didn't add it on prepare.
 
  However, they still work correctly with the released version of
  cordova-ios, and with master if you add the framework yourself. I suspect
  that this is an issue with plugman, though (and possibly just my
 install),
  and not the plugins themselves, as they seem to declare the dependency
  correctly.
 
 
  On Wed, Aug 6, 2014 at 10:39 PM, Steven Gill stevengil...@gmail.com
  wrote:
 
   Please review and vote on the release of this plugins release.
  
   Release issue: https://issues.apache.org/jira/browse/CB-7244
  
   The plugins have been published to
   dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-7244/
  
   The packages were published from their corresponding git tags:
   cordova-plugin-battery-status: 0.2.10 (490888663e)
   cordova-plugin-camera: 0.3.1 (823eb5d27a)
   cordova-plugin-console: 0.2.10 (361a73573b)
   cordova-plugin-contacts: 0.2.12 (5148d5ccd8)
   cordova-plugin-device: 0.2.11 (efd903fe88)
  
  
   cordova-plugin-device-motion: 0.2.9 (52c3348b18)
   cordova-plugin-device-orientation: 0.3.8 (fc8b28414f)
   cordova-plugin-dialogs: 0.2.9 (99e8f4c530)
   cordova-plugin-file: 1.3.0 (149044114f)
   cordova-plugin-file-transfer: 0.4.5 (a071c5bf9a)
  
  
   cordova-plugin-geolocation: 0.3.9 (438f50f8c4)
   cordova-plugin-globalization: 0.3.0 (bc3a4053ef)
   cordova-plugin-inappbrowser: 0.5.1 (c37b08e038)
   cordova-plugin-media: 0.2.12 (52ca8690db)
   cordova-plugin-media-capture: 0.3.2 (373d161668)
  
  
   cordova-plugin-network-information: 0.2.11 (00b71a7cd9)
   cordova-plugin-splashscreen: 0.3.2 (3b58cd69b3)
   cordova-plugin-statusbar: 0.1.7 (2ba62cb92c)
   cordova-plugin-vibration: 0.3.10 (4a4dc85a35)
  
  
   The blog post will be up tomorrow for review.
  
   Upon a successful vote I will upload the archives to dist/, upload
   them to the Plugins Registry, and post the corresponding blog post.
  
   Voting guidelines:
  
 
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md
  
   Voting will go on for a minimum of 48 hours.
  
   I vote +1:
   * Ran coho audit-license-headers over the relevant repos
   * Used `license-checker` to ensure all dependencies have
   Apache-compatible licenses
   * Ensured continuous build was green when repos were tagged
  
 

Re: Plugins Release blog post draft

[Bryan Higgins]

LGTM


On Fri, Aug 8, 2014 at 8:22 AM, Michal Mocny mmo...@chromium.org wrote:

 wait wait, a cordova organization on github with push access!?  Thats like,
 useful!  (and blasphemy)


 On Thu, Aug 7, 2014 at 9:33 PM, Andrew Grieve agri...@chromium.org
 wrote:

  LGTM
 
 
  On Thu, Aug 7, 2014 at 7:17 PM, Steven Gill stevengil...@gmail.com
  wrote:
 
   Please review and send PRs for changes. I can also add you to the repo
 if
   you want to edit directly on github and not worry about the PR.
  
  
  
 
 https://github.com/cordova/apache-blog-posts/blob/master/2014-08-08-plugins-release.md
  
 

Re: [DISCUSS] Plugins Release

[Bryan Higgins]

Thanks Steve.

I've done this, but RAT doesn't recognize zlib/libpng even though it has
been approved by Apache legal.

http://www.apache.org/legal/resolved.html


On Thu, Jul 31, 2014 at 7:18 PM, Steven Gill stevengil...@gmail.com wrote:

 So Globalization has issues with missing headers and needs a update to the
 notice file for new licenses. Both Blackberry and FFOS need to go do this
 before I release that plugin!

 What am I doing with test-harness? That isn't being released right? It also
 needs headers included + notice file updates.


 On Thu, Jul 31, 2014 at 7:18 AM, Bryan Higgins br...@bryanhiggins.net
 wrote:

  I'm into it! BlackBerry now supports File plugin roots and Globalization
 :)
 
 
  On Tue, Jul 29, 2014 at 3:29 PM, Steven Gill stevengil...@gmail.com
  wrote:
 
   How do you all feel about a plugins release?
  
   I can aim to start a vote thread tomorrow or Thursday if people feel
 good
   about it.
  
   -Steve
  
 

Re: [DISCUSS] Plugins Release

[Bryan Higgins]

Thanks Shaz! I couldn't find any other use of .ratignore in Cordova and
coho isn't configured to look for one.

Adding a ratExcludes section for plugin-globalization to
cordova-coho/src/repoutil.js did the trick.


On Fri, Aug 1, 2014 at 1:31 PM, Shazron shaz...@gmail.com wrote:

 You can add a .ratignore file, and add the note about the libs being
 approved by Apache legal.

 On Fri, Aug 1, 2014 at 6:41 AM, Bryan Higgins br...@bryanhiggins.net
 wrote:
  Thanks Steve.
 
  I've done this, but RAT doesn't recognize zlib/libpng even though it has
  been approved by Apache legal.
 
  http://www.apache.org/legal/resolved.html
 
 
  On Thu, Jul 31, 2014 at 7:18 PM, Steven Gill stevengil...@gmail.com
 wrote:
 
  So Globalization has issues with missing headers and needs a update to
 the
  notice file for new licenses. Both Blackberry and FFOS need to go do
 this
  before I release that plugin!
 
  What am I doing with test-harness? That isn't being released right? It
 also
  needs headers included + notice file updates.
 
 
  On Thu, Jul 31, 2014 at 7:18 AM, Bryan Higgins br...@bryanhiggins.net
  wrote:
 
   I'm into it! BlackBerry now supports File plugin roots and
 Globalization
  :)
  
  
   On Tue, Jul 29, 2014 at 3:29 PM, Steven Gill stevengil...@gmail.com
   wrote:
  
How do you all feel about a plugins release?
   
I can aim to start a vote thread tomorrow or Thursday if people feel
  good
about it.
   
-Steve
   
  
 

Re: [DISCUSS] Plugins Release

[Bryan Higgins]

I'm into it! BlackBerry now supports File plugin roots and Globalization :)


On Tue, Jul 29, 2014 at 3:29 PM, Steven Gill stevengil...@gmail.com wrote:

 How do you all feel about a plugins release?

 I can aim to start a vote thread tomorrow or Thursday if people feel good
 about it.

 -Steve

Re: missing documentation and missing major version bump

[Bryan Higgins]

This came up via an internal client who was using Cordova CLI with their
build script. They were passing in the BB keystore password for release
builds. It was easily resolved by adding --. While unfortunate that this
got through undocumented during a minor update, it's not a huge deal.

I agree with Mark that the separation provides greater flexibility so I
vote for not reverting this. Josh has already updated the help text. We
also need to update the BB10 platform guide for release builds and
deployment to named targets.

Re CI - we do run the unit tests on CI and invested a bunch of time to get
medic running on BB10. This specific test seems to have slipped through the
cracks. I will personally try to be more diligent about keeping that
updated and ensuring release validation gets done. My time has lately been
eaten up by another internal initiative leaving Josh with a lot on his
plate.


On Wed, Jul 30, 2014 at 10:24 AM, Mark Koudritsky kam...@google.com wrote:

 On Wed, Jul 30, 2014 at 1:46 AM, Carlos Santana csantan...@gmail.com
 wrote:

  Yep Michal I agree to update cli to pass down extra parameters to
 platform
  scripts like it used. this allow for greater flexibility in platform
  scripts and no hardcoded platform concerns in cli. No need to remove nopt
  if the this can be achieved.
 
 
 The list of flags to pass down to run will have to be hard coded in the
 cli, unless we want to go back to the manual position based argument
 parsing.

 I don't think we want
 cordova run --verbose
 to mean something different than
 cordova --verbose run
 but I think it's ok to expect that
 cordova run -- --verbose will mean something different.
 And it also allows things like
 cordova --verbose run -- --verbose

 The -- separation is exactly what allows the flexibility to pass anything
 to the run and build scripts without telling the cli what to expect or not
 expect after the -- .

 But going back to the origins of this discussion. The lack of documentation
 in help.txt about the -- thing is my bad. Thanks to Josh for adding it
 yesterday. But why revert the behavior? (and why only for the pre-4.0
 versions) If webworks is not affected, who is? Are those real people? If
 they have already hit, and possibly solved the problems caused by this
 change, do they want to revert back? Would be glad to hear from them.

Quick File plugin test on Android 2.3 needed

[Bryan Higgins]

It would be great if someone with a Gingerbread device could run the
cdvtests for my pull request. [1]

On BB10 Blobs are BlobConstructor objects. With the previous check, the
test failed as unsupported even though it does pass when allowed to run [2]

I'd feel better knowing this still works correctly on 2.3 before I submit
it.

Thanks!

[1] https://github.com/apache/cordova-plugin-file/pull/63

[2]
https://github.com/blackberry-webworks/cordova-plugin-file/commit/ea83ae259219919d9db2ba3006319bbd6e387126

Re: Should use only drawable folder for single application icon

[Bryan Higgins]

I have logged an issue related to this [1]

On 3.5.0-0.2.6, I can no longer specify a single default icon for Android.
Is this by design?

The docs imply it should be possible and it worked on 3.5.0-0.2.4

[1] https://issues.apache.org/jira/browse/CB-7132


On Sun, Jun 22, 2014 at 5:38 AM, Axel Nennker ignisvul...@gmail.com wrote:

 Changes are here with the commit message referring to CB-2606
 https://github.com/apache/cordova-lib/pull/30




 2014-06-21 19:51 GMT+02:00 Axel Nennker ignisvul...@gmail.com:

  I am currently changing android_parser.js because of CB-3571 and moved
 the
  icon handling code into its own method. I would implement this change and
  mark these commits as CB-2606.
  OK?
 
  Axel
  Am 21.06.2014 17:12 schrieb Andrew Grieve agri...@chromium.org:
 
  Jan, I think the rationale here is sound. Are you interested in adding
 this
  feature?
 
 
  On Sat, Jun 21, 2014 at 6:03 AM, Jan Velecký vve...@seznam.cz wrote:
 
   It is a thing of a concrete developer if he place more icons in
  different
   dimensions or not. In iOS developing, there must be more icons, but in
   Android, there can be only one icon in drawable folder. My
 experiences
   with use of only one 128×128 px icon in Android is positive, because
 on
  all
   testing devices icon looks great. When developer will be unhappy with
   system
   resized icon, he can put more icons with different resolutions.
  
   I'm using CLI and I'm using only one icon. And is annoying Cordova CLI
   everytime copy icon also on drawable-hdpi, drawable-ldpi folders and
 on
  and
   on instead of only into drawable folder. But You don't realize, that
  this
   is
   double bug, because this icon are in specific drawable folders, but in
  bad
   resolution... So benefits of this are missing.
  
   Behaviour to be expected of (Android) CLI:
  
  * icon with density not specified = copy this icon into drawable
  folder
  * icon with density specified = copy into intended drawable folder
  (drawable-density)
  
  
   Current behaviour of (Android) CLI:
  
  * icon with density not specified = copied this icon (and in
  addition
  all icon in the same resolution) into all of drawable folders
 except
  drawable folder...
  * icon with density specified = i don't tested this behaviour, I
  don't
  like byrocracy, so I don't use this scenario (on Android
 development
  naturally), but i think this scenario is functional
  
  
   Nice day,
  
   Jan Velecký.
  
  
   
   I disagree about Android doing a good job. We just don't notice it
  because
   we happen to have stupidly high quality template icons and we mostly
  test
   on
   hdpi and xhdpi devices. I'm sure if I ran this on an mdpi or ldpi
  device,
   the icon would be all distorted.
   
  
 
 

Re: [VOTE] Plugins Release (attempt 2)

[Bryan Higgins]

+1

- coho audit-license-headers
- coho verify-tags
- mobile-spec on cordova-blackberry@3.5.0

One failure for FT upload abort which I'll look into, but it's definitely
not a show stopper considering the improvements in this release.



On Tue, Jun 10, 2014 at 7:21 AM, Piotr Zalewa pzal...@mozilla.com wrote:

 +1 I've installed plugins and checked these which exist on Firefox OS

 Dnia Mon Jun  9 22:43:41 2014 Marcel Kinard pisze:

  I also verified the contents of the zip files against my local repos at
 that hash (diff -r). All looks good.

 On Jun 9, 2014, at 3:33 PM, Marcel Kinard cmarc...@gmail.com wrote:

  +1

 - Ran coho audit-license-headers, all looks good.
 - Ran coho verify-tags, all looks good.
 - Ran mobile-spec using Android Cordova platform 3.5.0 on Android 4.4.3.
 Ignoring the fails in Battery and Contacts, I see 2 other failing tests in
 Geolocation which I am tempted to ignore because this plugin is empty for
 Android since it falls back to the webview implementation for geolocation.

 On Jun 9, 2014, at 1:48 PM, Steven Gill stevengil...@gmail.com wrote:

 cordova-plugin-camera: 0.3.0 (4fa934e06f)
 cordova-plugin-console: 0.2.9 (f3764d8318)
 cordova-plugin-device: 0.2.10 (159d55eb1d)
 cordova-plugin-device-motion: 0.2.8 (51d58d6d29)

 cordova-plugin-device-orientation: 0.3.7 (d66777a007)
 cordova-plugin-dialogs: 0.2.8 (057d6cc4e9)
 cordova-plugin-file: 1.2.0 (e02d3d0f8e)
 cordova-plugin-file-transfer: 0.4.4 (db9eca0aa8)
 cordova-plugin-geolocation: 0.3.8 (a403b4abb6)

 cordova-plugin-globalization: 0.2.8 (9a4e8c81e5)
 cordova-plugin-inappbrowser: 0.5.0 (992306bbc5)
 cordova-plugin-media: 0.2.11 (ee68987d3b)
 cordova-plugin-media-capture: 0.3.1 (70cd9a0ee3)
 cordova-plugin-network-information: 0.2.9 (be5875f9d9)

 cordova-plugin-splashscreen: 0.3.1 (b3b7a561ab)
 cordova-plugin-statusbar: 0.1.6 (11195658af)
 cordova-plugin-vibration: 0.3.9 (b2fdbc1c92)





 --
 Piotr Zalewa
 Mozilla

Re: [Blackberry10] cordova emulate blackberry10 command fails

[Bryan Higgins]

If it is registered in DHCP leases, it should get automatically detected.
There is a known issue when you upgrade VMWare, the file gets blown away
and doesn't re-populate until you reboot the simulator.

What output do you get from 'blackberry-deploy -test ip' ?

You could also try manually registering the target (either by editing
blackberry10.json or running 'target add') and then use 'cordova emulate
--target'.


On Wed, May 28, 2014 at 4:18 PM, Martin Gonzalez 
martin.c.glez.g...@gmail.com wrote:

 I've been working with the Blackberry 10 simulator, recently I tried to
 deploy an app into the simulator but it always fails, even if the simulator
 is registered at .cordova\blackberry10.json.

 steps:
 cordova create BB10Test
 cordova platform add blackberry10
 cordova build blackberry10

 then
 cordova emulate blackberry10

 Error output:
 C:\Users\Administrator\BB10Testcordova emulate blackberry10
 Running command:
 c:\Users\Administrator\BB10Test\platforms\blackberry10\cordova\
 run.bat --emulator
 Searching for connected BlackBerry 10 Simulator (1/1)...
 No connected BlackBerry 10 emulator found
 Error:
 c:\Users\Administrator\BB10Test\platforms\blackberry10\cordova\run.bat: C
 ommand failed with exit code 2
 at ChildProcess.whenDone
 (C:\Users\Administrator\nodist\bin\node_modules\cor
 dova\node_modules\cordova-lib\src\cordova\superspawn.js:131:23)
 at ChildProcess.EventEmitter.emit (events.js:110:17)
 at maybeClose (child_process.js:992:16)
 at Process.ChildProcess._handle.onexit (child_process.js:1059:5)

 C:\Users\Administrator\BB10Test

 The simulator it doesn't have any password, it has activated the
 development mode, it has an ip address registered under the
 vmnetdhcp.leases, and well it's throwing this error, I have checked my
 environment and using the tools of Webworks 1.0, 2.0 and from the
 Blackberry Native SDK it throws the same error.

 Cordova: 3.5.0-0-2.4.0
 NodeJS(tested with): 10.26, 10.28, 11.12
 BBTools(tested with):  Webworks 1.0, 2.0 and Native SDK
 Simulator(tested with): 10.2.1.1925  10.3.0.440
 OS: Win 7 64 Bit

 Is there somebody else facing this problem?

 --
 Regards,
 Martin Gonzalez

Re: [Blackberry10] View logging events without the IDE

[Bryan Higgins]

Thanks for the write-up Martin!

For most Cordova devs WebInspector will be sufficient, but for plugin
development or performance tuning it can be useful to view the native
device logs.

Momentics IDE greatly simplifies this process. Just click Open Device
Logs from the Target Navigator


On Fri, May 23, 2014 at 5:38 PM, Martin Gonzalez Glez 
martin.c.glez.g...@gmail.com wrote:

 Deploying Blackberry 10 apps, I realize that it is possible to view the
 events on the device or emulator without the IDE usage.

 This can be an useful stuff to* debug any Cordova App*.

 *Requirements:*
 -Command line tools from the Native SDK or the tools from the BB10 WebWorks
 SDK (1.0 or 2.0).
 -Client SSH (PuTTY, Open SSH, Free SSH or any other).
 -Platform irrelevant.
 -Device or Simulator.

 First at all, it is required create a public and private RSA 4096 key, to
 do use the SSH client to create it.

*ssh-keygen -t rsa -b 4096*

 Set a name and path, then a passphrase, then it will be stored.
 Note: Windows user default path: %USERPROFILE%\.ssh\, here's where the ssh
 tools looks first.

 Then, connect your device or start the simulator, and activate the
 Development Mode at Settings, set a password and check for the IP provided.

 *Create a secure connection with the device:*

 ToolsDir=

- C:\Program Files\BlackBerry\BB10 WebWorks SDK
2.0.0.71\cordova-blackberry\bin\dependencies\bb-tools\bin
- C:\Program Files\Research In Motion\BlackBerry 10 WebWorks SDK
1.0.4.11\dependencies\tools\bin
- Native SDK bin path with the tools.

 Any of above paths should do the work, you can add any of those to the PATH
 variable or add it temporally in the current command prompt/shell.

 Type:

 *blackberry-connect [ip] -password [password-device] -sshPublicKey
 [path-to-the-key]*

 Example:

 *blackberry-connect 169.254.0.1 -password bbpass11 -sshPublicKey
 %USERPROFILE%/.ssh/id_rsa.pub*

 Note: The IP it is provided when you activate the development mode in
 settings.
 If you are using the simulator provide the ip located at the *south-left
 corner*, otherwise it's not going to work.

 If the connection fails, check:

- Development mode setting
- Settings -- Storage -- USB connection
- No other blackberry-connect command-line tool is already connected.
- Is not connected by the IDE.


 After the successful connected message, open a new command prompt/shell,
 and connect to the device with the SSH client.

 Type:
 *ssh devuser@IPDEVICE -i path-to-the/id_rsa*

 Example:
 PWD = C:/Users/admin

 *ssh dev@192.168.244.123 dev@192.168.244.123 -i .ssh\id_rsa*

 This time we are providing the private key to connect with the device. If
 everything went just fine, we are in a ssh connection with the device, we
 can explore the device storage content.

 Type to start to view logging events:

 *slog2info -w*

 Now you have devuser access to the device, and availability to view all
 events related with the applications installed in the device, similar to
 log cat from android.


 Type:

 *slog2info -h *

 In order to check all options.
 Keep both command prompt windows opened.

 Well, this is what I found, there you have the how to do it, the workflow
 can be followed to debug any app, and it can used to quickly and easy view
 the events on the native side, how your app behaves in there.

 RIM folks, is there any other alternative, besides of the IDE usage? or how
 are you guys doing this?

 Regards,
 Martin.

Re: BB10 on Cordova 3.4.0

[Bryan Higgins]

This chart is accurate (only Globalization and embedded web view are not
supported):
http://cordova.apache.org/docs/en/3.4.0/guide_support_index.md.html#Platform%20Support

WebWorks can be installed instead of the Native SDK to satisfy the
build/deploy dependencies, but the WebWorks APIs are not required.

In fact, all of the WebWorks APIs have been converted to Cordova plugins
are are hosted on the registry, so there is little reason to download it as
a multi-platform Cordova dev.


On Wed, May 21, 2014 at 12:15 PM, Marcel Kinard cmarc...@gmail.com wrote:

 Someone I was talking to today was under the impression that as of Cordova
 3.4.0, not all the APIs / core plugins are present on BB10, and that they
 would need to call WebWorks APIs directly where that presence (core
 plugins) is missing. I think they are wrong and that BB10 has full plugin
 support in 3.4.0, but wanted to verify with the RIM folks or others that
 have actual BB10 experience. Thanks!

Re: [Vote] 3.5.0 Blackberry Release

[Bryan Higgins]

+1

- confirmed signature and hashes
- verified tag 391072d85c
- tested CLI and bin/create workflow
- ran mobile-spec, 305/305 tests passing


On Wed, May 14, 2014 at 4:17 PM, Steven Gill stevengil...@gmail.com wrote:

 Please review and vote on this 3.5.0 Blackberry Release.

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

 Repos ready to be released have been published to dist/dev:
 https://dist.apache.org/repos/dist/dev/cordova/CB-6586/final

 The package was published from the corresponding git tag:
 cordova-blackberry: 3.5.0 (391072d85c)

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

 Voting guidelines:
 https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md

 Voting will go on for a minimum of 48 hours.

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

Re: Jira permissions?

[Bryan Higgins]

Michael - could you add me as well please? I face the same problem as
Marcel.

Thanks,
Bryan


On Tue, May 13, 2014 at 10:50 AM, Marcel Kinard cmarc...@gmail.com wrote:

 That fixed it, thanks Michal.

 I was able to assign issues to self earlier, which is why it seemed like a
 loss of permissions.

 On May 13, 2014, at 10:03 AM, Michal Mocny mmo...@chromium.org wrote:

  You were in the list of contributors, but were missing from the list of
 PMC
  on JIRA, so I added you.  Were you able to assign issues to self earlier?
  I'm not actually sure which roles are needed for what.

BB10 File Plugin

[Bryan Higgins]

I finally found some time to work on the promised update to the BB10 file
plugin. It now supports the same file system roots structure as Android and
iOS.

This is a complete re-write which uses the exec proxy rather than
clobbering the window objects. It's still using the webkit FileSystem API
under the hood, but has a few advantages over the previous implementation:

1. Ability to set HTML element src from FileEntry.toURL() regardless of
file system
2. Ability to copy files between file systems (ie persistent to root for
example)
3. resolveLocalFileSystemURI supports all file system types (persistent,
temporary, root, local)

All mobile-spec tests are passing, but I had to make one subtle change [1]
to the tests. spec 89 and 90 were failing in sequence but not on their own.
spec 88 writes a few extra bytes to the end of a file which is written to
again in the next tests. Those bytes show up (I think correctly) in the
tests which slice past the end of the file.

I have a pull request for this up on GitHub [2]. I will leave it up for a
few days to give people a chance to review it. In the meantime, I will test
this with the rest of the plugins and see if I can dig up more info on the
FileReader problem.

Thanks,
Bryan

[1]
https://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=blobdiff;f=autotest/tests/file.tests.js;h=e9d57885796bddeb5fe8a14e217a4cc9a81b5c51;hp=13ab2355494849419347c91226e3fdcdb2b57821;hb=49ecd9d00484a4a437524ff2cb6fd2e87a869013;hpb=5347f9f1e09224710c98c6bd9c3c143c833d018c

[2] https://github.com/apache/cordova-plugin-file/pull/44

Re: BB10 File Plugin

[Bryan Higgins]

The common JS for resolveLocalFileSystemURI and resolveLocalFileSystemURL
both call exec with resolveLocalFileSystemURL [1]

resolveLocalFileSystemURI is the new implementation [2] which handles the
exec call [3] rather than clobbering the window object

[1]
https://github.com/apache/cordova-plugin-file/blob/master/www/resolveLocalFileSystemURI.js#L64-L69

[2]
https://github.com/blackberry-webworks/cordova-plugin-file/blob/b7ba108f08b90ead2efb55bd40e1215fdde10cca/www/blackberry10/resolveLocalFileSystemURI.js

[3]
https://github.com/blackberry-webworks/cordova-plugin-file/blob/b7ba108f08b90ead2efb55bd40e1215fdde10cca/www/blackberry10/FileProxy.js#L43



On Mon, May 5, 2014 at 10:29 AM, Ian Clelland iclell...@chromium.orgwrote:

 That's great, Bryan! I'm really happy to see another platform get parity
 with iOS and Android.

 Looking through the PR, I'm trying to figure out what happened to
 resolveLocalFileSystemURL -- it looks like it was simply removed in this
 version, with the deprecated relsolveLocalFileSystemURI put back in it's
 place. Was that intended?



 On Mon, May 5, 2014 at 9:13 AM, Bryan Higgins br...@bryanhiggins.net
 wrote:

  I finally found some time to work on the promised update to the BB10 file
  plugin. It now supports the same file system roots structure as Android
 and
  iOS.
 
  This is a complete re-write which uses the exec proxy rather than
  clobbering the window objects. It's still using the webkit FileSystem API
  under the hood, but has a few advantages over the previous
 implementation:
 
  1. Ability to set HTML element src from FileEntry.toURL() regardless of
  file system
  2. Ability to copy files between file systems (ie persistent to root for
  example)
  3. resolveLocalFileSystemURI supports all file system types (persistent,
  temporary, root, local)
 
  All mobile-spec tests are passing, but I had to make one subtle change
 [1]
  to the tests. spec 89 and 90 were failing in sequence but not on their
 own.
  spec 88 writes a few extra bytes to the end of a file which is written to
  again in the next tests. Those bytes show up (I think correctly) in the
  tests which slice past the end of the file.
 
  I have a pull request for this up on GitHub [2]. I will leave it up for a
  few days to give people a chance to review it. In the meantime, I will
 test
  this with the rest of the plugins and see if I can dig up more info on
 the
  FileReader problem.
 
  Thanks,
  Bryan
 
  [1]
 
 
 https://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=blobdiff;f=autotest/tests/file.tests.js;h=e9d57885796bddeb5fe8a14e217a4cc9a81b5c51;hp=13ab2355494849419347c91226e3fdcdb2b57821;hb=49ecd9d00484a4a437524ff2cb6fd2e87a869013;hpb=5347f9f1e09224710c98c6bd9c3c143c833d018c
 
  [2] https://github.com/apache/cordova-plugin-file/pull/44
 

Re: Missed CB-2606's birthday

[Bryan Higgins]

Merged

Thanks Axel and Sergey for driving this!


On Thu, Apr 24, 2014 at 4:30 AM, Marc Weiner mhweiner...@gmail.com wrote:

 I would love to see more support on this issue as well.


 On Thu, Apr 24, 2014 at 1:54 AM, Axel Nennker ignisvul...@gmail.com
 wrote:

  https://issues.apache.org/jira/browse/CB-2606 is now one year old.
 
  Happy birthday!
 
  Please merge
  https://github.com/apache/cordova-cli/pull/166
 

Re: [DISCUSS] Plugin master branches

[Bryan Higgins]

+1

I think the registry has been around for long enough that the vast majority
of users won't be installing directly from git.


On Tue, Apr 22, 2014 at 9:44 AM, Ian Clelland iclell...@chromium.orgwrote:

 I totally agree that we should do this.

 I think that once the current plugin release is complete, I can set up the
 branches so that the master branch is for development, and we can go from
 there.

 Is it a requirement that plugins be tagged in git for npm to function? I
 thought that the plugins were uploaded, zipped, to our couch server, for
 each release, and that there was no further communication with the git
 repository? It shouldn't be a problem to go back and make sure they're
 properly tagged, but I'm just wondering if it's still a necessity.

 Ian

 On Mon, Apr 21, 2014 at 9:27 PM, Jesse purplecabb...@gmail.com wrote:

  I am seeing more and more pull requests that aren't easy merges because
  people are starting their work from the master branch, and not dev.
 
  We discussed *a long time ago* that at some point, we would consider
 master
  to be the bleeding edge of each plugin, and we could then get rid of the
  dev branches.  The requirements to make this possible included, using a
  branch/tag for every npm release of the plugin, and making sure that
 plugin
  dependencies were correctly mapped.
 
  Has anyone given this any more thought, and do we have any idea when we
  will make the switch?
 
  Cheers,
Jesse
 
 
  @purplecabbage
  risingj.com
 

Re: BB10 com.blackberry.utils plugin .so?

[Bryan Higgins]

We removed the binaries from source since the plugins are being fetched
from the registry now.

The device/simulator files are just renamed versions of arm and x86. There
is a build script[1] which copies everything where it needs to be.

'jake build' should do the trick

[1]
https://github.com/blackberry/cordova-blackberry-plugins/blob/master/scripts/build.js



On Mon, Apr 14, 2014 at 4:31 PM, Marcel Kinard cmarc...@gmail.com wrote:

 For BB10, cordova-plugin-contacts has a couple pre-reqs, one of which is
 the plugin com.blackberry.utils. The plugin.xml for that utils plugin
 referenes a couple lib-files device/libutils.so and
 simulator/libutils.so, which appears to be compiled from C source. I'd
 like to build them myself.

 If I install that utils plugin via the CLI (fetched from plugin repo)
 those .so files are present. If I go to the github source repo at [1] those
 .so files used to be present but are no longer present. Actually they were
 removed by a recent commit [2]. There are makefiles to build arm and x86,
 but not to build the device and simulator so's as previously present
 before the recent commit [2]. So how do I build device/libutils.so and
 simulator/libutils.so? Are they simply renamed versions of arm and x86?
 Thanks!

 [1]
 https://github.com/blackberry/cordova-blackberry-plugins/tree/master/plugin/com.blackberry.utils/src/blackberry10/native

 [2]
 https://github.com/blackberry/cordova-blackberry-plugins/commit/304cfddcd7e478fad5990bf12715d0e7f1205648

Re: [DISCUSS] Plugin release this week / early next

[Bryan Higgins]

+1


On Tue, Apr 15, 2014 at 12:24 PM, Jesse MacFadyen
purplecabb...@gmail.comwrote:

 Yes. We need this to happen way more frequently.

 Sent from my Windows PhoneFrom: James Jong
 Sent: ‎4/‎15/‎2014 9:17 AM
 To: dev@cordova.apache.org
 Subject: Re: [DISCUSS] Plugin release this week / early next
 SGTM.  It has been awhile since our last plugins release.
 -James Jong

 On Apr 15, 2014, at 11:53 AM, Ian Clelland iclell...@chromium.org wrote:

  It's been a while since we did a plugin release, and I have a number of
  changes to File / Media that I'd like to make public. It looks every
 plugin
  has had at least one commit since the last release, though, so maybe we
  want to do a release of the full suite.
 
  (The one minimum commit for each appears to be an Added NOTICE file, so
  it might be good from an ASF-compliance POV)
 
  From what I can see this morning:
 
  cordova-plugin-battery-status: release 0.2.8, 1 commit
  cordova-plugin-camera: release 0.2.9, 12 commits
  cordova-plugin-console: release 0.2.8, 1 commit
  cordova-plugin-contacts: release 0.2.10, 5 commits
  cordova-plugin-device: release 0.2.9, 3 commits
  cordova-plugin-device-motion: release 0.2.7, 2 commits
  cordova-plugin-device-orientation: release 0.3.6, 3 commits
  cordova-plugin-dialogs: release 0.2.7, 5 commits
  cordova-plugin-file: release 1.0.2, 25 commits
  cordova-plugin-file-transfer: release 0.4.3, 7 commits
  cordova-plugin-geolocation: release 0.3.7, 4 commits
  cordova-plugin-globalization: release 0.2.7, 4 commits
  cordova-plugin-inappbrowser: release 0.3.4, 12 commits
  cordova-plugin-media: release 0.2.10, 4 commits
  cordova-plugin-media-capture: release 0.2.9, 8 commits
  cordova-plugin-network-information: release 0.2.8, 3 commits
  cordova-plugin-splashscreen: release 0.2.8, 3 commits
  cordova-plugin-statusbar: release 0.1.5, 4 commits
  cordova-plugin-vibration: release 0.3.8, 1 commit
 
 
  I have a couple of changes that I want to get in to media-capture today,
  but after that I'm happy with the state of the file-related plugins.
 
  Thoughts? We could start a vote thread tomorrow or Thursday, and release
 on
  Monday if it passes.
 
  Ian

Re: Proposal for independent platform releases

[Bryan Higgins]

I don't have permission to edit or add comments to this


On Tue, Apr 15, 2014 at 3:22 PM, Steven Gill stevengil...@gmail.com wrote:


 https://docs.google.com/document/d/1OmK_fezEiv-LIPIw242kAdKhThqfD39xbSfvjWFOmjM/edit?usp=sharing

 Very much a work in progress. I would love some more info on both option 1
 and option 2 for people who are interested. Add your comments and changes
 to the doc!

Re: Duplicate plugin preferences - any docs on config/defaults xml mechanisms

[Bryan Higgins]

Sounds like a bug if two preferences of the same name end up in the
platform config.xml. I would encourage you to log this in our JIRA system:

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

Platform specific preferences can be specified using the platform element,
which I recently discovered was undocumented.

https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=blobdiff;f=docs/en/edge/config_ref/index.md;h=9c32672403f1ceffce4278aa7e1fa6add7065946;hp=2df993147957cfe6f626f8a08e4a47889e4d;hb=7598207d0e4395905c009c056947a5a7c9930b1a;hpb=b28cb8be613f637f28dbfd3c0db2bd193e7abb51



On Mon, Apr 14, 2014 at 9:57 AM, Matt Scafidi-McGuire 
matt.scafidi-mcgu...@dealer.com wrote:

 We're using cordova to build for iOS  Android and we struggle with a few
 issues with the defaults/config mechanisms for plugin preferences.  Perhaps
 we just don't understand how it's meant to be used or perhaps we've
 uncovered a bug.  These first two issues lead us to the problem I'm writing
 about.

 We can't put custom preferences in the shared config file that have a copy
 in the defaults.xml, because both end up in the generated config file.  It
 seems like preferences shouldn't be repeated in the generated config file
 whether they contradict each other or not.  It seems like any preference or
 attribute in the shared config should override one found in the
 defaults.xml.

 We don't want to put platform-specific preferences in the shared
 config.xml file because it'll end up in the config files for both
 platforms.  Although we could leave them in there cluttering the final
 generated config file, we'd rather not.  The fact that we already have to
 edit the defaults.xml files to solve the previous problem led us to this
 solution.  We put all shared values in the shared config.xml and any
 platform specific settings in the respective defaults.xml.

 That worked well for us until we upgraded.  It seems as part of the
 upgrade, the defaults.xml files were all cleared.  After uninstalling 
 reinstalling each plugin (no plugins update?), the defaults.xml files were
 full of defaults and our custom settings were all gone.

 So what are we missing?  Is there any documentation on the most effective
 use of these files?

 If we leave custom preferences in the shared config.xml, how do we prevent
 duplication/competition with the copies in defaults.xml?

 Is there yet another place for platform specific settings?  Is there
 anyway to prevent nuking the defaults.xml when upgrading?

 Thanks,
 MattDuplicate plugin preferences - any docs on config/defaults xml
 mechanisms



 Matt Scafidi-McGuire | Senior User Interface Developer
 matt.scafidi-mcgu...@dealer.commailto:matt.scafidi-mcgu...@dealer.com

 [Dealer.com]

Re: support on phonegap/cordova? ---- Request for Cordova User Group Mailing List

[Bryan Higgins]

+1


On Fri, Apr 11, 2014 at 9:56 AM, Lisa Seacat DeLuca ldel...@us.ibm.comwrote:

 After attending ApacheCon it was clear that most projects have a user
 group mailing list to handle questions like this rather than forwarding
 people to a product specific distribution.  I know there is a big community
 around PhoneGap and the Google Group has a lot of great existing content
 but we should create a user group for Cordova to make developers more aware
 that we exist.  Right now if you ask a developer if they know what Cordova
 is they stare at your blankly... but if you ask then what Phonegap is they
 are more likely to know.  This would be a small change that could go a long
 way to helping to disrupt that way of thinking.  thoughts? +1's?


 Lisa

 Lisa Seacat DeLuca
 Mobile Engineer | t: +415.787.4589 | 
 *ldel...@apache.org*ldel...@apache.org| |
 *ldel...@us.ibm.com* ldel...@us.ibm.com | 
 *lisaseacat.com*http://www.lisaseacat.com/| [image:
 follow @LisaSeacat on twitter] http://www.twitter.com/LisaSeacat| [image:
 follow Lisa Seacat DeLuca on linkedin]http://www.linkedin.com/in/lisaseacat





 From:Andrew Grieve agri...@chromium.org
 To:dev dev@cordova.apache.org
 Date:04/09/2014 06:16 PM
 Subject:Re: support on phonegap/cordova?
 Sent by:agri...@google.com
 --



 StackOverflow works really well as well. If it's a possible but in the
 framework or an Apache plugin though, this is the list :)


 On Wed, Apr 9, 2014 at 6:21 AM, Ray Camden rayca...@adobe.com wrote:

  I'd use the Google Group:
 https://groups.google.com/forum/#!forum/phonegap
  
  From: smo s.la...@gmail.com
  Sent: Wednesday, April 09, 2014 2:35 AM
  To: dev@cordova.apache.org
  Subject: support on phonegap/cordova?
 
  hi
 
  where must i post to get support on phonegap/cordova ios ?
 
  thanks
 
 

Re: support on phonegap/cordova? ---- Request for Cordova User Group Mailing List

[Bryan Higgins]

Good points Steve!

I will definitely check in on SO, especially for BB related questions.


On Fri, Apr 11, 2014 at 3:26 PM, Steven Gill stevengil...@gmail.com wrote:

 From my experience of helping out on the PG google group, many people ask
 very simple questions and don't bother searching.

 My worries about having a users group:
 * searchability of answers. We would have to point people towards markmail
 to search (or Google)
 * lack of responding from committers. If we end up not being responsive,
 doesn't look good for Cordova.
 * flood of simple basic questions over and over

 With stack overflow, we can point users to a well established community for
 answering questions. Our community seems to enjoy gathering SO points and
 building rep. We take advantage of the search and ranking ability on SO.
 The cordova/phonegap tags are also very highly used and answered already.

 I agree with Michal that we should direct people to SO from our site.

 We also offer support on #cordova on freenode (even though this was
 intended to be more of a dev channel)

 My own  personal thoughts about the PG Google group have been that we
 should migrate users to SO. Unfortunately, it is never easy forcing a well
 established community to change.
 +1 to stackoverflow.


 On Fri, Apr 11, 2014 at 8:43 AM, Steven Gill stevengil...@gmail.com
 wrote:

  +1 to Michal.
 
  I would prefer stack overflow over more email.
  On Apr 11, 2014 7:58 AM, Michal Mocny mmo...@chromium.org wrote:
 
   Not sure I would use the argument make users less aware of phonegap
 as
  a
   reason for this ;) but I agree that its a bit confusing for existing
  users
   of cordova core to be directed to phonegap support (see timely reply to
  the
   original thread from another user).
  
   I much prefer directing user questions to stack overflow, though, where
   there is much better support for handling duplicate questions,
  prioritizing
   useful answers, and you generally get much more community contributions
  for
   answering questions, so I'd really prefer we advertise that avenue for
   support on our website first and foremost.
  
   For user questions that do need to go to a mailing list (is there ever
 a
   case?), I guess I don't mind which list it goes to (dev@ or users@).
  I
   just mind the inevitably frequent repetitive low quality questions by
  users
   who just didn't do their research.  Stack overflow solves that problem
  much
   better.
  
   My 2cents.
  
   -Michal
  
  
   On Fri, Apr 11, 2014 at 10:23 AM, Bryan Higgins 
 br...@bryanhiggins.net
   wrote:
  
+1
   
   
On Fri, Apr 11, 2014 at 9:56 AM, Lisa Seacat DeLuca 
  ldel...@us.ibm.com
wrote:
   
 After attending ApacheCon it was clear that most projects have a
 user
 group mailing list to handle questions like this rather than
  forwarding
 people to a product specific distribution.  I know there is a big
community
 around PhoneGap and the Google Group has a lot of great existing
   content
 but we should create a user group for Cordova to make developers
 more
aware
 that we exist.  Right now if you ask a developer if they know what
Cordova
 is they stare at your blankly... but if you ask then what Phonegap
 is
they
 are more likely to know.  This would be a small change that could
 go
  a
long
 way to helping to disrupt that way of thinking.  thoughts? +1's?


 Lisa

 Lisa Seacat DeLuca
 Mobile Engineer | t: +415.787.4589 | *ldel...@apache.org*
ldel...@apache.org| |
 *ldel...@us.ibm.com* ldel...@us.ibm.com | *lisaseacat.com*
http://www.lisaseacat.com/| [image:
 follow @LisaSeacat on twitter] http://www.twitter.com/LisaSeacat
 |
[image:
 follow Lisa Seacat DeLuca on linkedin]
http://www.linkedin.com/in/lisaseacat





 From:Andrew Grieve agri...@chromium.org
 To:dev dev@cordova.apache.org
 Date:04/09/2014 06:16 PM
 Subject:Re: support on phonegap/cordova?
 Sent by:agri...@google.com
 --



 StackOverflow works really well as well. If it's a possible but in
  the
 framework or an Apache plugin though, this is the list :)


 On Wed, Apr 9, 2014 at 6:21 AM, Ray Camden rayca...@adobe.com
  wrote:

  I'd use the Google Group:
 https://groups.google.com/forum/#!forum/phonegap
  
  From: smo s.la...@gmail.com
  Sent: Wednesday, April 09, 2014 2:35 AM
  To: dev@cordova.apache.org
  Subject: support on phonegap/cordova?
 
  hi
 
  where must i post to get support on phonegap/cordova ios ?
 
  thanks
 
 


   
  
 

Re: [VOTE] cordova-plugman@0.21.0

[Bryan Higgins]

+1


On Mon, Apr 7, 2014 at 11:15 AM, Michal Mocny mmo...@chromium.org wrote:

 +1.

 (I noticed for format of sha and md5 files changed (coho patch to strip
 weird pgp formatting), but the format now doesn't match either sha512sum or
 pgp CLI tools. The contents do match so its fine)



 On Mon, Apr 7, 2014 at 1:01 AM, Ian Clelland iclell...@chromium.org
 wrote:

  +1, plugman looks good from here.
 
 
  On Mon, Apr 7, 2014 at 12:48 AM, Steven Gill stevengil...@gmail.com
  wrote:
 
   Please review and vote on the release of cordova-plugman.
  
   cordova-plugman@0.21.0 has been published here:
   *https://dist.apache.org/repos/dist/dev/cordova/CB-6245/
   https://dist.apache.org/repos/dist/dev/cordova/CB-6245/*
  
  
   The package was published from the corresponding git tag:
   cordova-plugman: 0.21.0 (b2f3a130d3)
  
   Upon a successful vote I will upload plugman archive to dist/ and
 publish
   it to npm. I will then post a vote for the cordova-cli followed by a
   corresponding blog post.
  
   Voting will go on for a minimum of 24 hours.
  
   I vote +1.
  
 

Re: cordova launcher icon support https://github.com/apache/cordova-cli/pull/126

[Bryan Higgins]

Great, thanks Sergey!

I commented on the pull request. It looks like this is almost ready to be
merged.

I'd urge any other platform maintainers to take a look / test this out ASAP.


On Thu, Apr 3, 2014 at 5:40 PM, Sergey Grebnov (Akvelon) 
v-seg...@microsoft.com wrote:

 Pushed additional improvements [1]
 1. BB10 support by Bryan (w/ additional minor improvements)
 2. Due to BB10 native packager issue and for consistency reasons switched
 from cdv/gap: platform attribute to platform element. Updated config
 sample can be found here[2].

 [1] https://github.com/AxelNennker/cordova-cli/pull/4
 [2]  https://gist.github.com/sgrebnov/9949313

 Thx!!
 Sergey
 -Original Message-
 From: Bryan Higgins [mailto:br...@bryanhiggins.net]
 Sent: Thursday, April 3, 2014 9:29 PM
 To: dev@cordova.apache.org
 Subject: Re: cordova launcher icon support
 https://github.com/apache/cordova-cli/pull/126

 I've got a branch up for bb10 here:

 https://github.com/blackberry/cordova-cli/commit/a3da36cdc31ea4d090f5c63b2930160af474d3bc

 Right now it fails to build if icons exist for any other platform or an
 icon element exists within platform name=blackberry10.


 On Thu, Apr 3, 2014 at 11:23 AM, Bryan Higgins br...@bryanhiggins.net
 wrote:

  All I am saying is that from an end user perspective it would be nice
  if we were consistent. If there are problems with the current platform
  tag, those should be filed as issues in JIRA and fixed. Or we can
  decide it was a mistake and go with platform attribute on preferences
  as well since it was really an undocumented feature up until this point.
 
  I'm with Andrew in favouring the element since it is consistent with
  plugin.xml.
 
  As it stands now getIcons doesn't return icon elements specified
  within platform. So the platform config will end up with an icon
  element that the parser didn't know about.
 
 
  On Thu, Apr 3, 2014 at 10:34 AM, Axel Nennker ignisvul...@gmail.com
 wrote:
 
  Which supports my suspicion that platform was introduced for
  preference elements but implemented in a way that developers can
  stick any child element into it. Which would not have any
  consequences if a developer would do it because ConfigParser.js does
  not honor the platform element.
  Platform in config.xml is only parsed while config.xml is merged into
  platform-config.xml
 
  This: platform name=iosnameios hello world/name/platform
  does not work and the developer gets not feedback that this element
  is not used (even on ios).
 
 
  2014-04-03 15:42 GMT+02:00 Bryan Higgins br...@bryanhiggins.net:
 
   I added this to edge when it came up on the list a few weeks ago.
  
  
  
  https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=blobdiff
  ;f=docs/en/edge/config_ref/index.md;h=9c32672403f1ceffce4278aa7e1fa6a
  dd7065946;hp=2df993147957cfe6f626f8a08e4a47889e4d;hb=7598207d0e43
  95905c009c056947a5a7c9930b1a;hpb=b28cb8be613f637f28dbfd3c0db2bd193e7a
  bb51
  
  
   On Thu, Apr 3, 2014 at 9:38 AM, Andrew Grieve
   agri...@chromium.org
   wrote:
  
Feel pretty strongly that we shouldn't introduce gap: prefix.
cdv: is
  bad
enough :(. I'm sure PG Build will accept whatever syntax we come
up
  with.
   
It's true that platform isn't documented (that I know of), but
it's consistent with plugin.xml and I think being able to put any
elements
  in
there makes it quite flexible.
   
   
On Thu, Apr 3, 2014 at 6:20 AM, Bryan Higgins
br...@bryanhiggins.net
wrote:
   
 My point is only that we should be consistent. If the platform
  element
   is
 used for preference, then why introduce an attribute which does
 the
   same
 thing for icon?

 Also, I've seen platform=, cdv:platform= and gap:platform=
 within
  the
pull
 requests.


 On Thu, Apr 3, 2014 at 9:08 AM, Axel Nennker
 ignisvul...@gmail.com
  
 wrote:

  Hi Jonathan,
  considering how difficult is is to get this icon thing is I
  would
   like
to
  postpone splash screen discussion after this is merged or
  rejected.
  On the other hand there were discussions on this list about
  splash
screen
  support/changes not so long ago. I did not join those because
  even
   this
  very small icon thing - that does not even introduce new
  elements/formats/whatnot that would require us to support it
  until
   hell
  freezes - takes ages to get accepted.
 
  One thing regarding icon vs splash: I think that
  icon/launcher_icon
   is
 more
  an OS thing while splash is more a app thing.
 
  cheers
  Axel
 
 
 
  2014-04-03 14:46 GMT+02:00 Jonathan Bond-Caron 
jbo...@gdesolutions.com
 :
 
   On Thu Apr 3 05:06 AM, Axel Nennker wrote:
It is a shame that CB-2606 is unresolved this long. We
should
   have
   something
rolled out soon.
   
  
   +1, thoughts on splashscreens

Re: cordova launcher icon support https://github.com/apache/cordova-cli/pull/126

[Bryan Higgins]

You need to rebase your branch so the new commits appear after
apache:master/HEAD


On Fri, Apr 4, 2014 at 10:39 AM, Axel Nennker ignisvul...@gmail.com wrote:

 This is probably a stupid question but: Why do I see so many changed files
 here
 https://github.com/apache/cordova-cli/pull/126/files
 like Readme.md which I do not want in this pull request.
 I did a get fetch upstream from the original repo to my local repo and
 pushed that back to my githup repo. I thought that this makes the current
 PR smaller.


 2014-04-04 16:00 GMT+02:00 Bryan Higgins br...@bryanhiggins.net:

  Great, thanks Sergey!
 
  I commented on the pull request. It looks like this is almost ready to be
  merged.
 
  I'd urge any other platform maintainers to take a look / test this out
  ASAP.
 
 
  On Thu, Apr 3, 2014 at 5:40 PM, Sergey Grebnov (Akvelon) 
  v-seg...@microsoft.com wrote:
 
   Pushed additional improvements [1]
   1. BB10 support by Bryan (w/ additional minor improvements)
   2. Due to BB10 native packager issue and for consistency reasons
 switched
   from cdv/gap: platform attribute to platform element. Updated config
   sample can be found here[2].
  
   [1] https://github.com/AxelNennker/cordova-cli/pull/4
   [2]  https://gist.github.com/sgrebnov/9949313
  
   Thx!!
   Sergey
   -Original Message-
   From: Bryan Higgins [mailto:br...@bryanhiggins.net]
   Sent: Thursday, April 3, 2014 9:29 PM
   To: dev@cordova.apache.org
   Subject: Re: cordova launcher icon support
   https://github.com/apache/cordova-cli/pull/126
  
   I've got a branch up for bb10 here:
  
  
 
 https://github.com/blackberry/cordova-cli/commit/a3da36cdc31ea4d090f5c63b2930160af474d3bc
  
   Right now it fails to build if icons exist for any other platform or an
   icon element exists within platform name=blackberry10.
  
  
   On Thu, Apr 3, 2014 at 11:23 AM, Bryan Higgins br...@bryanhiggins.net
   wrote:
  
All I am saying is that from an end user perspective it would be nice
if we were consistent. If there are problems with the current
 platform
tag, those should be filed as issues in JIRA and fixed. Or we can
decide it was a mistake and go with platform attribute on preferences
as well since it was really an undocumented feature up until this
  point.
   
I'm with Andrew in favouring the element since it is consistent with
plugin.xml.
   
As it stands now getIcons doesn't return icon elements specified
within platform. So the platform config will end up with an icon
element that the parser didn't know about.
   
   
On Thu, Apr 3, 2014 at 10:34 AM, Axel Nennker ignisvul...@gmail.com
   wrote:
   
Which supports my suspicion that platform was introduced for
preference elements but implemented in a way that developers can
stick any child element into it. Which would not have any
consequences if a developer would do it because ConfigParser.js does
not honor the platform element.
Platform in config.xml is only parsed while config.xml is merged
 into
platform-config.xml
   
This: platform name=iosnameios hello world/name/platform
does not work and the developer gets not feedback that this element
is not used (even on ios).
   
   
2014-04-03 15:42 GMT+02:00 Bryan Higgins br...@bryanhiggins.net:
   
 I added this to edge when it came up on the list a few weeks ago.



   
 https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=blobdiff
;f=docs/en/edge/config_ref/index.md
 ;h=9c32672403f1ceffce4278aa7e1fa6a
   
 dd7065946;hp=2df993147957cfe6f626f8a08e4a47889e4d;hb=7598207d0e43
   
 95905c009c056947a5a7c9930b1a;hpb=b28cb8be613f637f28dbfd3c0db2bd193e7a
bb51


 On Thu, Apr 3, 2014 at 9:38 AM, Andrew Grieve
 agri...@chromium.org
 wrote:

  Feel pretty strongly that we shouldn't introduce gap: prefix.
  cdv: is
bad
  enough :(. I'm sure PG Build will accept whatever syntax we come
  up
with.
 
  It's true that platform isn't documented (that I know of), but
  it's consistent with plugin.xml and I think being able to put
 any
  elements
in
  there makes it quite flexible.
 
 
  On Thu, Apr 3, 2014 at 6:20 AM, Bryan Higgins
  br...@bryanhiggins.net
  wrote:
 
   My point is only that we should be consistent. If the platform
element
 is
   used for preference, then why introduce an attribute which
 does
   the
 same
   thing for icon?
  
   Also, I've seen platform=, cdv:platform= and gap:platform=
   within
the
  pull
   requests.
  
  
   On Thu, Apr 3, 2014 at 9:08 AM, Axel Nennker
   ignisvul...@gmail.com

   wrote:
  
Hi Jonathan,
considering how difficult is is to get this icon thing is I
would
 like
  to
postpone splash screen discussion after this is merged or
rejected.
On the other hand

Re: [VOTE] cordoav-cli@3.4.1-0.1.0, cordova-plugman@0.21.0 and cordova-ios@3.4.1

[Bryan Higgins]

The other problem we face is the actual repo being unusable for a period of
time unless you know how to fiddle with package.json / npm-shrinkwrap.json.

At the very least this should be pointed out on the README, but even that
doesn't seem friendly to potential contributors.

I'm in favour of bumping the version number in CLI after the vote for cases
like this where we're releasing tools together. Those testing the CLI for
release can bump up the plugman version locally.

Otherwise we should vote on plugman first, then update CLI and vote on
that...


On Fri, Apr 4, 2014 at 12:33 PM, Parashuram Narasimhan (MS OPEN TECH) 
panar...@microsoft.com wrote:

 Can we also include the Windows Phone and Windows Platform, specifically
 for the following bugs/pull requests

 1.  Windows 8 - https://github.com/apache/cordova-windows/pull/20 -
 This is more of a regression in case VS2013 is installed. With the build
 announcement yesterday, this could be higher priority. Note that this is
 not yet merged in.
 2.  Windows Phone 8 - https://github.com/apache/cordova-wp8/pull/28 -
 This could affect the users using the emulator.

 -Original Message-
 From: Axel Nennker [mailto:ignisvul...@gmail.com]
 Sent: Friday, April 4, 2014 9:21 AM
 To: dev
 Subject: Re: [VOTE] cordoav-cli@3.4.1-0.1.0, cordova-plugman@0.21.0 and
 cordova-ios@3.4.1

 Is there a chance to get the cb-2606 patch for launcer icon support into a
 release some time no too far?

 Axel
 Am 04.04.2014 10:01 schrieb Steven Gill stevengil...@gmail.com:

  Please review and vote on the release of this cordova-cli,
  cordova-plugman and cordova-ios release.
 
  cordova-cli@3.4.1-0.1.0, cordova-plugman@0.21.0 and cordova-ios@3.4.1
  have been published here:
  *https://dist.apache.org/repos/dist/dev/cordova/CB-6245/
  https://dist.apache.org/repos/dist/dev/cordova/CB-6245/*
 
 
  The packages were published from their corresponding git tags:
  cordova-cli: 3.4.1-0.1.0 (b769a304be)
  cordova-plugman: 0.21.0 (b2f3a130d3)
  cordova-ios: 3.4.1 (a96d2360fa)
 
  Upon a successful vote I will upload the cli  plugman archives to
  dist/ and publish them to npm. Cordova-ios will be uploaded to
  dist/platforms. I will then post the corresponding blog post.
 
  Voting will go on for a minimum of 24 hours.
 
  I vote +1.
 
  If people want individual vote threads for each item, let me know and
  I will create them instead of this thread.
 

Re: [VOTE] cordoav-cli@3.4.1-0.1.0, cordova-plugman@0.21.0 and cordova-ios@3.4.1

[Bryan Higgins]

SGTM


On Fri, Apr 4, 2014 at 1:38 PM, Ian Clelland iclell...@chromium.org wrote:

 What about only adding the shrinkwrap file to git just before release, on
 the release branch? Then only published releases on npm (and on
 dist.apache.org) will include that file, and the only people who have to
 delete it manually are those people testing the release candidate. Anyone
 getting master from git will not have that file.


 On Fri, Apr 4, 2014 at 1:25 PM, Bryan Higgins br...@bryanhiggins.net
 wrote:

  Right, but someone outside of this group stumbling upon the repo on
 GitHub
  won't be able to use it unless they know to delete the shrinkwrap file.
 I'd
  rather the process be a bit more cumbersome for us and preserve the
  integrity of repo.
 
 
  On Fri, Apr 4, 2014 at 1:11 PM, David Kemp drk...@chromium.org wrote:
 
   If we make the proposed change to the CLI package.json (change the
  plugman
   dependency to =0.21.0-rc),
   then all that is required for testing is to delete the shrinkwrap file.
  
   That means a little less hackery to test the package that is being
 voted
   on.
  
   We have currently made those changes on the fly in the CI to get it
  working
   again.
  
  
  
   On Fri, Apr 4, 2014 at 12:57 PM, Bryan Higgins br...@bryanhiggins.net
   wrote:
  
The other problem we face is the actual repo being unusable for a
  period
   of
time unless you know how to fiddle with package.json /
   npm-shrinkwrap.json.
   
At the very least this should be pointed out on the README, but even
  that
doesn't seem friendly to potential contributors.
   
I'm in favour of bumping the version number in CLI after the vote for
   cases
like this where we're releasing tools together. Those testing the CLI
  for
release can bump up the plugman version locally.
   
Otherwise we should vote on plugman first, then update CLI and vote
 on
that...
   
   
On Fri, Apr 4, 2014 at 12:33 PM, Parashuram Narasimhan (MS OPEN
 TECH) 
panar...@microsoft.com wrote:
   
 Can we also include the Windows Phone and Windows Platform,
   specifically
 for the following bugs/pull requests

 1.  Windows 8 -
  https://github.com/apache/cordova-windows/pull/20-
 This is more of a regression in case VS2013 is installed. With the
   build
 announcement yesterday, this could be higher priority. Note that
 this
   is
 not yet merged in.
 2.  Windows Phone 8 -
   https://github.com/apache/cordova-wp8/pull/28-
 This could affect the users using the emulator.

 -Original Message-
 From: Axel Nennker [mailto:ignisvul...@gmail.com]
 Sent: Friday, April 4, 2014 9:21 AM
 To: dev
 Subject: Re: [VOTE] cordoav-cli@3.4.1-0.1.0,
  cordova-plugman@0.21.0and
 cordova-ios@3.4.1

 Is there a chance to get the cb-2606 patch for launcer icon support
   into
a
 release some time no too far?

 Axel
 Am 04.04.2014 10:01 schrieb Steven Gill stevengil...@gmail.com
 :

  Please review and vote on the release of this cordova-cli,
  cordova-plugman and cordova-ios release.
 
  cordova-cli@3.4.1-0.1.0, cordova-plugman@0.21.0 and
   cordova-ios@3.4.1
  have been published here:
  *https://dist.apache.org/repos/dist/dev/cordova/CB-6245/
  https://dist.apache.org/repos/dist/dev/cordova/CB-6245/*
 
 
  The packages were published from their corresponding git tags:
  cordova-cli: 3.4.1-0.1.0 (b769a304be)
  cordova-plugman: 0.21.0 (b2f3a130d3)
  cordova-ios: 3.4.1 (a96d2360fa)
 
  Upon a successful vote I will upload the cli  plugman archives
 to
  dist/ and publish them to npm. Cordova-ios will be uploaded to
  dist/platforms. I will then post the corresponding blog post.
 
  Voting will go on for a minimum of 24 hours.
 
  I vote +1.
 
  If people want individual vote threads for each item, let me know
  and
  I will create them instead of this thread.
 

   
  
 

Re: [VOTE] cordoav-cli@3.4.1-0.1.0, cordova-plugman@0.21.0 and cordova-ios@3.4.1

[Bryan Higgins]

No, it's not a huge deal. I was only suggesting we avoid it if possible,
otherwise update the README.

Our internal CI starting failing as soon as that commit was made as well.
Anyone using this downstream will need to make changes.


On Fri, Apr 4, 2014 at 1:45 PM, Steven Gill stevengil...@gmail.com wrote:

 Sorry, didn't mean to hit send on that last message quite so quickly.

 We could add release branches but it would require us to change our release
 process for them.

 Isn't master only broken until we release. If the process is completed
 within 24hours, is having master broken a huge deal? Most people will use
 npm to install cordova anyways.



 On Fri, Apr 4, 2014 at 10:43 AM, Steven Gill stevengil...@gmail.com
 wrote:

  We don't have release branches for CLI + Plugman.
 
 
  On Fri, Apr 4, 2014 at 10:40 AM, Bryan Higgins br...@bryanhiggins.net
 wrote:
 
  SGTM
 
 
  On Fri, Apr 4, 2014 at 1:38 PM, Ian Clelland iclell...@chromium.org
  wrote:
 
   What about only adding the shrinkwrap file to git just before release,
  on
   the release branch? Then only published releases on npm (and on
   dist.apache.org) will include that file, and the only people who have
  to
   delete it manually are those people testing the release candidate.
  Anyone
   getting master from git will not have that file.
  
  
   On Fri, Apr 4, 2014 at 1:25 PM, Bryan Higgins br...@bryanhiggins.net
   wrote:
  
Right, but someone outside of this group stumbling upon the repo on
   GitHub
won't be able to use it unless they know to delete the shrinkwrap
  file.
   I'd
rather the process be a bit more cumbersome for us and preserve the
integrity of repo.
   
   
On Fri, Apr 4, 2014 at 1:11 PM, David Kemp drk...@chromium.org
  wrote:
   
 If we make the proposed change to the CLI package.json (change the
plugman
 dependency to =0.21.0-rc),
 then all that is required for testing is to delete the shrinkwrap
  file.

 That means a little less hackery to test the package that is being
   voted
 on.

 We have currently made those changes on the fly in the CI to get
 it
working
 again.



 On Fri, Apr 4, 2014 at 12:57 PM, Bryan Higgins 
  br...@bryanhiggins.net
 wrote:

  The other problem we face is the actual repo being unusable for
 a
period
 of
  time unless you know how to fiddle with package.json /
 npm-shrinkwrap.json.
 
  At the very least this should be pointed out on the README, but
  even
that
  doesn't seem friendly to potential contributors.
 
  I'm in favour of bumping the version number in CLI after the
 vote
  for
 cases
  like this where we're releasing tools together. Those testing
 the
  CLI
for
  release can bump up the plugman version locally.
 
  Otherwise we should vote on plugman first, then update CLI and
  vote
   on
  that...
 
 
  On Fri, Apr 4, 2014 at 12:33 PM, Parashuram Narasimhan (MS OPEN
   TECH) 
  panar...@microsoft.com wrote:
 
   Can we also include the Windows Phone and Windows Platform,
 specifically
   for the following bugs/pull requests
  
   1.  Windows 8 -
https://github.com/apache/cordova-windows/pull/20-
   This is more of a regression in case VS2013 is installed. With
  the
 build
   announcement yesterday, this could be higher priority. Note
 that
   this
 is
   not yet merged in.
   2.  Windows Phone 8 -
 https://github.com/apache/cordova-wp8/pull/28-
   This could affect the users using the emulator.
  
   -Original Message-
   From: Axel Nennker [mailto:ignisvul...@gmail.com]
   Sent: Friday, April 4, 2014 9:21 AM
   To: dev
   Subject: Re: [VOTE] cordoav-cli@3.4.1-0.1.0,
cordova-plugman@0.21.0and
   cordova-ios@3.4.1
  
   Is there a chance to get the cb-2606 patch for launcer icon
  support
 into
  a
   release some time no too far?
  
   Axel
   Am 04.04.2014 10:01 schrieb Steven Gill 
  stevengil...@gmail.com
   :
  
Please review and vote on the release of this cordova-cli,
cordova-plugman and cordova-ios release.
   
cordova-cli@3.4.1-0.1.0, cordova-plugman@0.21.0 and
 cordova-ios@3.4.1
have been published here:
*https://dist.apache.org/repos/dist/dev/cordova/CB-6245/
https://dist.apache.org/repos/dist/dev/cordova/CB-6245/*
   
   
The packages were published from their corresponding git
 tags:
cordova-cli: 3.4.1-0.1.0 (b769a304be)
cordova-plugman: 0.21.0 (b2f3a130d3)
cordova-ios: 3.4.1 (a96d2360fa)
   
Upon a successful vote I will upload the cli  plugman
  archives
   to
dist/ and publish them to npm. Cordova-ios will be uploaded
 to
dist/platforms. I will then post the corresponding blog
 post.
   
Voting will go

Re: Blackberry copyright in js files

[Bryan Higgins]

The files are all Apache 2.0 licensed.

The 2012 headers came from code donated by RIM which was previously hosted
on GitHub. The recent one is probably a copy/paste mistake by Josh.

I *think* they can all be removed.


On Fri, Apr 4, 2014 at 4:26 PM, Martin Gonzalez Glez 
martin.c.glez.g...@gmail.com wrote:

 Hi everyone, in some blackberry files, I have noticed some blackberry
 copyright statements:


 https://github.com/blackberry/cordova-blackberry/blob/cb_6398/blackberry10/bin/templates/project/cordova/lib/params.js#L2


 https://github.com/blackberry/cordova-blackberry/blob/cb_6398/blackberry10/bin/templates/project/cordova/lib/params.js#L2


 https://github.com/blackberry/cordova-blackberry/blob/cb_6398/blackberry10/bin/templates/project/cordova/lib/debugtoken-helper.js#L2

 Something like:

 Copyright 2014 BlackBerry Limited.

 Copyright 2012 Research In Motion Limited.


 Is not supposed to all files should be under Apache License, Version 2.0?.

 Just asking if this is normal?

Re: cordova launcher icon support https://github.com/apache/cordova-cli/pull/126

[Bryan Higgins]

OK, great. I saw cdv:platform within the pull request [1] so I wanted to
confirm that wasn't the direction that was decided on.

The platform element [2] has been in for a while. There was a discussion
about it on the list a few weeks ago. It's being used to prevent config
from being copied into the platform config.xml files.

BlackBerry10 supports the widget icon element in its platform config.xml
file. With the change as it is right now, it will actually break the build
process because it won't find those icons.

Recommended sizes are 114x114 and 94x94, but the platform will accept other
sizes and picks the best icon based on the device. So I suppose the correct
thing to do is copy only those sizes if specified, otherwise copy the
closest match. The rest of the entries need to be filtered out.

I'll try to get something up later today.

[1] https://github.com/apache/cordova-cli/pull/126/files
[2]
https://github.com/apache/cordova-cli/commit/45e80ac1b2c73a18155e74ac286067a4299742d8#diff-6e0c580ec9d220fc4b32a0ffd9b41595R151



On Thu, Apr 3, 2014 at 5:06 AM, Axel Nennker ignisvul...@gmail.com wrote:

 Bryan,
 where is this platform element support implemented?
 It is not in
 https://github.com/apache/cordova-cli/blob/master/src/ConfigParser.js
 right?

 Regarding cdv:platform: No this is the opposite. There are other threads
 in this mailing (search for CB-2606).
 To summarize those:
 All proposals that included new elements like cdv:icon or new attributes
 for the icon element cdv:platform did not get broad support.
 All proposals related to the gap prefix or namespaces did not get broad
 support.
 Dropping the w3c widget standard for config.xml was postponed to later.
 Hooks work but feel like a nailed on afterwards solution.

 So I came up with the proposal to select the icons be the width/height
 attributes. This proposal does not cover all use case e.g.: If you want
 different icons on different platforms then this will not work. but it is
 simple

 The pro side:
 - standard icon sizes seem to be quite distinct per platform.
 - this proposal is already implemented for Android, FirefoxOS, WP8. Sergey
 works on ios.
 - it does not fiddle with xml stuff
 - easy to implement and easy to understand by devs

 It is a shame that CB-2606 is unresolved this long. We should have
 something rolled out soon.

 -axel




 2014-04-02 22:21 GMT+02:00 Bryan Higgins br...@bryanhiggins.net:

  config.xml already supports a platform element for platform specific
 config
 
  Is the proposal to also add an attribute cdv:platform which serves the
 same
  purpose?
 
 
  On Wed, Apr 2, 2014 at 4:09 PM, Sergey Grebnov (Akvelon) 
  v-seg...@microsoft.com wrote:
 
   Hi,
  
   Have we agreed to proceed with explicit icons definition via config.xml
   similar to PG Build[1]? -  If so I'm going to add iOS support and
 update
   our docs. So we will have support of iOS, Android,  FxOS, WP8 and
  Windows8.
   Adding icons to a new platform will be easy, similar to [2]
  
   Some my thoughts: Adding explicit icon references to config.xml looks
   redundant since in most cases developers will still use default icon
  names
   following platform guides so we can just proceed with predefined folder
   ('res' as an example) and documenting folder structure and icon names
 for
   different platforms. - Sort of 'merges' where we replace app resources
   using some special logic. But it could be useful if we share same image
   between platforms or reference the same image for different needs
 inside
   single platform.
  
   [1]
  
 
 http://docs.build.phonegap.com/en_US/3.3.0/configuring_icons_and_splash.md.html#Icons%20and%20Splash%20Screens
   [2]
  
 
 https://github.com/apache/cordova-cli/pull/126/files#diff-45a2a0f22289a5eb91348499a5053cd8R170
  
   Thx!
   Sergey
   -Original Message-
   From: Axel Nennker [mailto:ignisvul...@gmail.com]
   Sent: Thursday, March 13, 2014 5:05 PM
   To: dev
   Subject: RE: cordova launcher icon support
   https://github.com/apache/cordova-cli/pull/126
  
   Please fork https://github.com/AxelNennker/cordova-cli and send a PR
 for
   wp.
   Thanks
   Axel
Am 13.03.2014 13:18 schrieb Sergey Grebnov (Akvelon) 
   v-seg...@microsoft.com:
  
Hi
1.  It seems pull request does not contain related changes for
windows8 and wp8. I may help here if nobody has already started
working in this direction.
2. I also can't replace default splash screen image following
instructions below. It seems to be PhoneGap Build specific, isn't it?
Do we support changing splash screen as part of cordova-cli?
   
   
 http://cordova.apache.org/docs/en/3.4.0/config_ref_images.md.html#Icon
s%20and%20Splash%20Screens
   
Thx!
Sergey
-Original Message-
From: Axel Nennker [mailto:ignisvul...@gmail.com]
Sent: Saturday, February 22, 2014 1:44 AM
To: dev
Subject: Re: cordova launcher icon support
https://github.com/apache/cordova-cli/pull/126

Re: cordova launcher icon support https://github.com/apache/cordova-cli/pull/126

[Bryan Higgins]

My point is only that we should be consistent. If the platform element is
used for preference, then why introduce an attribute which does the same
thing for icon?

Also, I've seen platform=, cdv:platform= and gap:platform= within the pull
requests.


On Thu, Apr 3, 2014 at 9:08 AM, Axel Nennker ignisvul...@gmail.com wrote:

 Hi Jonathan,
 considering how difficult is is to get this icon thing is I would like to
 postpone splash screen discussion after this is merged or rejected.
 On the other hand there were discussions on this list about splash screen
 support/changes not so long ago. I did not join those because even this
 very small icon thing - that does not even introduce new
 elements/formats/whatnot that would require us to support it until hell
 freezes - takes ages to get accepted.

 One thing regarding icon vs splash: I think that icon/launcher_icon is more
 an OS thing while splash is more a app thing.

 cheers
 Axel



 2014-04-03 14:46 GMT+02:00 Jonathan Bond-Caron jbo...@gdesolutions.com:

  On Thu Apr 3 05:06 AM, Axel Nennker wrote:
   It is a shame that CB-2606 is unresolved this long. We should have
  something
   rolled out soon.
  
 
  +1, thoughts on splashscreens or other images?
 
 
 

Re: cordova launcher icon support https://github.com/apache/cordova-cli/pull/126

[Bryan Higgins]

I added this to edge when it came up on the list a few weeks ago.

https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=blobdiff;f=docs/en/edge/config_ref/index.md;h=9c32672403f1ceffce4278aa7e1fa6add7065946;hp=2df993147957cfe6f626f8a08e4a47889e4d;hb=7598207d0e4395905c009c056947a5a7c9930b1a;hpb=b28cb8be613f637f28dbfd3c0db2bd193e7abb51


On Thu, Apr 3, 2014 at 9:38 AM, Andrew Grieve agri...@chromium.org wrote:

 Feel pretty strongly that we shouldn't introduce gap: prefix. cdv: is bad
 enough :(. I'm sure PG Build will accept whatever syntax we come up with.

 It's true that platform isn't documented (that I know of), but it's
 consistent with plugin.xml and I think being able to put any elements in
 there makes it quite flexible.


 On Thu, Apr 3, 2014 at 6:20 AM, Bryan Higgins br...@bryanhiggins.net
 wrote:

  My point is only that we should be consistent. If the platform element is
  used for preference, then why introduce an attribute which does the same
  thing for icon?
 
  Also, I've seen platform=, cdv:platform= and gap:platform= within the
 pull
  requests.
 
 
  On Thu, Apr 3, 2014 at 9:08 AM, Axel Nennker ignisvul...@gmail.com
  wrote:
 
   Hi Jonathan,
   considering how difficult is is to get this icon thing is I would like
 to
   postpone splash screen discussion after this is merged or rejected.
   On the other hand there were discussions on this list about splash
 screen
   support/changes not so long ago. I did not join those because even this
   very small icon thing - that does not even introduce new
   elements/formats/whatnot that would require us to support it until hell
   freezes - takes ages to get accepted.
  
   One thing regarding icon vs splash: I think that icon/launcher_icon is
  more
   an OS thing while splash is more a app thing.
  
   cheers
   Axel
  
  
  
   2014-04-03 14:46 GMT+02:00 Jonathan Bond-Caron 
 jbo...@gdesolutions.com
  :
  
On Thu Apr 3 05:06 AM, Axel Nennker wrote:
 It is a shame that CB-2606 is unresolved this long. We should have
something
 rolled out soon.

   
+1, thoughts on splashscreens or other images?
   
   
   
  
 

Re: cordova launcher icon support https://github.com/apache/cordova-cli/pull/126

[Bryan Higgins]

All I am saying is that from an end user perspective it would be nice if we
were consistent. If there are problems with the current platform tag, those
should be filed as issues in JIRA and fixed. Or we can decide it was a
mistake and go with platform attribute on preferences as well since it was
really an undocumented feature up until this point.

I'm with Andrew in favouring the element since it is consistent with
plugin.xml.

As it stands now getIcons doesn't return icon elements specified within
platform. So the platform config will end up with an icon element that the
parser didn't know about.


On Thu, Apr 3, 2014 at 10:34 AM, Axel Nennker ignisvul...@gmail.com wrote:

 Which supports my suspicion that platform was introduced for preference
 elements but implemented in a way that developers can stick any child
 element into it. Which would not have any consequences if a developer would
 do it because ConfigParser.js does not honor the platform element.
 Platform in config.xml is only parsed while config.xml is merged into
 platform-config.xml

 This: platform name=iosnameios hello world/name/platform does not
 work and the developer gets not feedback that this element is not used
 (even on ios).


 2014-04-03 15:42 GMT+02:00 Bryan Higgins br...@bryanhiggins.net:

  I added this to edge when it came up on the list a few weeks ago.
 
 
 
 https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=blobdiff;f=docs/en/edge/config_ref/index.md;h=9c32672403f1ceffce4278aa7e1fa6add7065946;hp=2df993147957cfe6f626f8a08e4a47889e4d;hb=7598207d0e4395905c009c056947a5a7c9930b1a;hpb=b28cb8be613f637f28dbfd3c0db2bd193e7abb51
 
 
  On Thu, Apr 3, 2014 at 9:38 AM, Andrew Grieve agri...@chromium.org
  wrote:
 
   Feel pretty strongly that we shouldn't introduce gap: prefix. cdv: is
 bad
   enough :(. I'm sure PG Build will accept whatever syntax we come up
 with.
  
   It's true that platform isn't documented (that I know of), but it's
   consistent with plugin.xml and I think being able to put any elements
 in
   there makes it quite flexible.
  
  
   On Thu, Apr 3, 2014 at 6:20 AM, Bryan Higgins br...@bryanhiggins.net
   wrote:
  
My point is only that we should be consistent. If the platform
 element
  is
used for preference, then why introduce an attribute which does the
  same
thing for icon?
   
Also, I've seen platform=, cdv:platform= and gap:platform= within the
   pull
requests.
   
   
On Thu, Apr 3, 2014 at 9:08 AM, Axel Nennker ignisvul...@gmail.com
wrote:
   
 Hi Jonathan,
 considering how difficult is is to get this icon thing is I would
  like
   to
 postpone splash screen discussion after this is merged or rejected.
 On the other hand there were discussions on this list about splash
   screen
 support/changes not so long ago. I did not join those because even
  this
 very small icon thing - that does not even introduce new
 elements/formats/whatnot that would require us to support it until
  hell
 freezes - takes ages to get accepted.

 One thing regarding icon vs splash: I think that icon/launcher_icon
  is
more
 an OS thing while splash is more a app thing.

 cheers
 Axel



 2014-04-03 14:46 GMT+02:00 Jonathan Bond-Caron 
   jbo...@gdesolutions.com
:

  On Thu Apr 3 05:06 AM, Axel Nennker wrote:
   It is a shame that CB-2606 is unresolved this long. We should
  have
  something
   rolled out soon.
  
 
  +1, thoughts on splashscreens or other images?
 
 
 

   
  
 

Re: cordova launcher icon support https://github.com/apache/cordova-cli/pull/126

[Bryan Higgins]

I've got a branch up for bb10 here:
https://github.com/blackberry/cordova-cli/commit/a3da36cdc31ea4d090f5c63b2930160af474d3bc

Right now it fails to build if icons exist for any other platform or an
icon element exists within platform name=blackberry10.


On Thu, Apr 3, 2014 at 11:23 AM, Bryan Higgins br...@bryanhiggins.netwrote:

 All I am saying is that from an end user perspective it would be nice if
 we were consistent. If there are problems with the current platform tag,
 those should be filed as issues in JIRA and fixed. Or we can decide it was
 a mistake and go with platform attribute on preferences as well since it
 was really an undocumented feature up until this point.

 I'm with Andrew in favouring the element since it is consistent with
 plugin.xml.

 As it stands now getIcons doesn't return icon elements specified within
 platform. So the platform config will end up with an icon element that the
 parser didn't know about.


 On Thu, Apr 3, 2014 at 10:34 AM, Axel Nennker ignisvul...@gmail.comwrote:

 Which supports my suspicion that platform was introduced for preference
 elements but implemented in a way that developers can stick any child
 element into it. Which would not have any consequences if a developer
 would
 do it because ConfigParser.js does not honor the platform element.
 Platform in config.xml is only parsed while config.xml is merged into
 platform-config.xml

 This: platform name=iosnameios hello world/name/platform does
 not
 work and the developer gets not feedback that this element is not used
 (even on ios).


 2014-04-03 15:42 GMT+02:00 Bryan Higgins br...@bryanhiggins.net:

  I added this to edge when it came up on the list a few weeks ago.
 
 
 
 https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=blobdiff;f=docs/en/edge/config_ref/index.md;h=9c32672403f1ceffce4278aa7e1fa6add7065946;hp=2df993147957cfe6f626f8a08e4a47889e4d;hb=7598207d0e4395905c009c056947a5a7c9930b1a;hpb=b28cb8be613f637f28dbfd3c0db2bd193e7abb51
 
 
  On Thu, Apr 3, 2014 at 9:38 AM, Andrew Grieve agri...@chromium.org
  wrote:
 
   Feel pretty strongly that we shouldn't introduce gap: prefix. cdv: is
 bad
   enough :(. I'm sure PG Build will accept whatever syntax we come up
 with.
  
   It's true that platform isn't documented (that I know of), but it's
   consistent with plugin.xml and I think being able to put any elements
 in
   there makes it quite flexible.
  
  
   On Thu, Apr 3, 2014 at 6:20 AM, Bryan Higgins br...@bryanhiggins.net
   wrote:
  
My point is only that we should be consistent. If the platform
 element
  is
used for preference, then why introduce an attribute which does the
  same
thing for icon?
   
Also, I've seen platform=, cdv:platform= and gap:platform= within
 the
   pull
requests.
   
   
On Thu, Apr 3, 2014 at 9:08 AM, Axel Nennker ignisvul...@gmail.com
 
wrote:
   
 Hi Jonathan,
 considering how difficult is is to get this icon thing is I would
  like
   to
 postpone splash screen discussion after this is merged or
 rejected.
 On the other hand there were discussions on this list about splash
   screen
 support/changes not so long ago. I did not join those because even
  this
 very small icon thing - that does not even introduce new
 elements/formats/whatnot that would require us to support it until
  hell
 freezes - takes ages to get accepted.

 One thing regarding icon vs splash: I think that
 icon/launcher_icon
  is
more
 an OS thing while splash is more a app thing.

 cheers
 Axel



 2014-04-03 14:46 GMT+02:00 Jonathan Bond-Caron 
   jbo...@gdesolutions.com
:

  On Thu Apr 3 05:06 AM, Axel Nennker wrote:
   It is a shame that CB-2606 is unresolved this long. We should
  have
  something
   rolled out soon.
  
 
  +1, thoughts on splashscreens or other images?
 
 
 

   
  
 

Re: cordova launcher icon support https://github.com/apache/cordova-cli/pull/126

[Bryan Higgins]

config.xml already supports a platform element for platform specific config

Is the proposal to also add an attribute cdv:platform which serves the same
purpose?


On Wed, Apr 2, 2014 at 4:09 PM, Sergey Grebnov (Akvelon) 
v-seg...@microsoft.com wrote:

 Hi,

 Have we agreed to proceed with explicit icons definition via config.xml
 similar to PG Build[1]? -  If so I'm going to add iOS support and update
 our docs. So we will have support of iOS, Android,  FxOS, WP8 and Windows8.
 Adding icons to a new platform will be easy, similar to [2]

 Some my thoughts: Adding explicit icon references to config.xml looks
 redundant since in most cases developers will still use default icon names
 following platform guides so we can just proceed with predefined folder
 ('res' as an example) and documenting folder structure and icon names for
 different platforms. - Sort of 'merges' where we replace app resources
 using some special logic. But it could be useful if we share same image
 between platforms or reference the same image for different needs inside
 single platform.

 [1]
 http://docs.build.phonegap.com/en_US/3.3.0/configuring_icons_and_splash.md.html#Icons%20and%20Splash%20Screens
 [2]
 https://github.com/apache/cordova-cli/pull/126/files#diff-45a2a0f22289a5eb91348499a5053cd8R170

 Thx!
 Sergey
 -Original Message-
 From: Axel Nennker [mailto:ignisvul...@gmail.com]
 Sent: Thursday, March 13, 2014 5:05 PM
 To: dev
 Subject: RE: cordova launcher icon support
 https://github.com/apache/cordova-cli/pull/126

 Please fork https://github.com/AxelNennker/cordova-cli and send a PR for
 wp.
 Thanks
 Axel
  Am 13.03.2014 13:18 schrieb Sergey Grebnov (Akvelon) 
 v-seg...@microsoft.com:

  Hi
  1.  It seems pull request does not contain related changes for
  windows8 and wp8. I may help here if nobody has already started
  working in this direction.
  2. I also can't replace default splash screen image following
  instructions below. It seems to be PhoneGap Build specific, isn't it?
  Do we support changing splash screen as part of cordova-cli?
 
  http://cordova.apache.org/docs/en/3.4.0/config_ref_images.md.html#Icon
  s%20and%20Splash%20Screens
 
  Thx!
  Sergey
  -Original Message-
  From: Axel Nennker [mailto:ignisvul...@gmail.com]
  Sent: Saturday, February 22, 2014 1:44 AM
  To: dev
  Subject: Re: cordova launcher icon support
  https://github.com/apache/cordova-cli/pull/126
 
  there is a pull request that implements this gap: prefix and phonegap
  namespace stuff but this is Cordova and we have cdv: as prefix and
  another
  namespace: xmlns:cdv=http://cordova.apache.org/ns/1.0;
  Looks like config.json adapted by both projects is a way out.
 
 
  2014-02-21 21:36 GMT+01:00 Don Coleman don.cole...@gmail.com:
 
   Icons are a drag. Explicit configuration sucks, but is the way to go.
  
   It would be nice if the Cordova solution was compatible with
   PhoneGap Build icons
   http://docs.build.phonegap.com/en_US/3.1.0/configuring_icons_and_spl
   as h.md.html#Icons%20and%20Splash%20Screens
   
   .
  
  
  
  
   On Fri, Feb 21, 2014 at 11:24 AM, Axel Nennker
   ignisvul...@gmail.com
   wrote:
  
What is your favorite explicit configuration?
Am 21.02.2014 16:49 schrieb Brian LeRoux b...@brian.io:
   
 As much as I'd like a single icon source I do not think it is
 the right path. To do this right I think we need to audit all
 possible icons for
each
 platform and create a map to analyze what could be distilled
 across platforms.

 Ideally we'd accept a vector format (SVG) and generate all these
ridiculous
 sizes but designers will not like this. Pixel perfection,
 especially
   for
a
 springboard icon, is paramount. The only way we're getting there
 safely
is
 zero magic and explicit configuration.

 Lame, I know.


 On Thu, Feb 20, 2014 at 1:07 AM, Axel Nennker
 ignisvul...@gmail.com
 wrote:

  How about this strategy:
 
  project_dir/config.xml
  - no new elements in config.xml like cdv:icon
  - no new attributes in icon element in config.xml like
  cdv:platform
   or
  gap:platform
  - do not invent stuff we have to support for the rest of our
 life.
 
  On all platforms:
  - if config.xml contains a icon src=whatever.png/ without
  any attributes like width and heigth, then copy that src to to
  all
   platform
  specific  locations where that platform expects launcher icons
  and
update
  config files like manifest.webapp on FirefoxOS if there isn't
  a
specific
  icon element for that location (see later).
  - no downscaling of icons to lower sizes
  - no upscaling of icons to higher sizes
  - do not add dependencies to new node modules (e.g. to parse
  icon
files)
 
  On Android:
  I) if there is a specific  icon src=icon.png width=48 /
  then
   copy
  that icon.png to 

Re: Looking at the new File API pragmatically

[Bryan Higgins]

+1 to replacing toURL with toNativeURL behaviour

For accessing the root file system, what I'd personally like is a ROOT
filesystem type for requestFileSystem. If the file-system-roots plugin
provides that I think we should definitely pull it in.

For the camera and media plugins on BB10 we return a full path relative to
the file system root as the native apps save into default locations. I
wonder if there is an opportunity to add additional roots which map to
default locations for pictures, music and video (maybe also documents?). It
seems like that would be super useful for media player apps or downloaders.

On Tue, Apr 1, 2014 at 4:50 AM, Anis KADRI anis.ka...@gmail.com wrote:

 On Tue, Apr 1, 2014 at 3:28 AM, Ian Clelland iclell...@chromium.org
 wrote:

  On Mon, Mar 31, 2014 at 4:33 PM, Ian Clelland iclell...@chromium.org
  wrote:
 
   On Mon, Mar 31, 2014 at 4:20 PM, Michal Mocny mmo...@chromium.org
  wrote:
  
   On Mon, Mar 31, 2014 at 3:39 PM, Ian Clelland iclell...@chromium.org
   wrote:
This is ugly, though, and is going to get worse over time, and
 become
  a
division between Cordova and any platforms which actually implement
  the
File API correctly. I'd like to propose switching the behaviour of
.toURL(), to match .toNativeURL -- returning a webview-usable URL by
default -- and implementing some other method or property to get the
  CDV
URL when it's necessary.
   
  
   Everything you've said sounds like its all upside to make the switch.
   So
   I'm curious, when would CDV URL be necessary/useful over file/content
   urls?
  
  
   cdvfile:// URLs would still be necessary when dealing with files that
  just
   don't *have* an alternate representation. There currently aren't any of
   those, but we could implement virtual file systems entirely inside of a
   plugin, and those would require a cdvfile:// URL to be read.
  
   I think we'd recommend them when saving URLs to persistent storage, if
   there is any chance that the actual files could be moved / migrated,
 and
  we
   could hide that from the user by giving them a more abstract identifier
   than one which specifies a physical location.
   cdvfile://localhost/persistent/my/file.txt might be more durable over
  time
   than file:///data/data/com.company.package/files/my/file.txt, perhaps
   across OS upgrades.
  
 
  Actually, forget all of that.
 
  Your question had me looking for reasons to advocate users using
 cdvfile://
  URLs, when perhaps none exist. The truth of the matter is this: The
 cdvfile
  URL has two parts: the filesystem name, and the full path. Those two
 parts
  form a consistent internal representation for all of the types of file
 that
  the plugin can handle, and so all of the internal / native bits of the
 file
  plugin use them almost exclusively. We make sure that every FileEntry and
  DirectoryEntry has those parts, and we only need to turn them into a URL
  for passing them across the bridge.
 
  One day someone may discover a great reason to use deliberately use
 cdvfile
  URLs at the application level; until then, they're available, and we can
  continue to use them internally to simplify the plugin code, enforce the
  sandboxing, and make everything generally more consistent and efficient,
  and users shouldn't need to know or care what the URLs in use actually
 are.
 

 I agree with this as long as the URLs are useable in the WebView (as src
 attributes for example). If they're not, I also suggest that we return URLs
 that are useable (file:///, content:/// or whatever) by default.

 As for filesystems (temp or persistent), I think most developers will use
 whatever the default is. BUT they should be able to specify where they want
 to store their data if they feel like it without using a third-party
 plugin.


 
  Ian
 

Re: Looking at the new File API pragmatically

[Bryan Higgins]

I'm in the process of converting the bb10 file plugin to use the exec proxy
rather than clobbering common js. Once that's done, I'll take a look at
adding some additional file system roots.


On Tue, Apr 1, 2014 at 10:24 AM, Ian Clelland iclell...@chromium.orgwrote:

 On Tue, Apr 1, 2014 at 10:14 AM, Bryan Higgins br...@bryanhiggins.net
 wrote:

  +1 to replacing toURL with toNativeURL behaviour
 

 I think that's what I'll do. I'm also adding a toInternalURL method --
 not because it's necessarily useful for end users, but because we can use
 it as the single method to construct URLs for transport across the bridge.


  For accessing the root file system, what I'd personally like is a ROOT
  filesystem type for requestFileSystem. If the file-system-roots plugin
  provides that I think we should definitely pull it in.
 

 It does provide that; although I haven't enabled it by default. I've been
 pretty wary of allowing JavaScript to arbitrarily access *everything* on
 the entire device that is permitted by the OS.


 
  For the camera and media plugins on BB10 we return a full path relative
 to
  the file system root as the native apps save into default locations. I
  wonder if there is an opportunity to add additional roots which map to
  default locations for pictures, music and video (maybe also documents?).
 It
  seems like that would be super useful for media player apps or
 downloaders.
 

 That's the whole point of the file-system-roots plugin -- on Android, it
 adds things like sdcard, external cache, external persistent files,
 documetns, etc. On iOS, it gives library, documents, cache, bundle, and a
 couple of non-icloud-synced versions of them. I'd love to get a set of
 useful BlackBerry file system roots as well.

 Ian

 
  On Tue, Apr 1, 2014 at 4:50 AM, Anis KADRI anis.ka...@gmail.com wrote:
 
   On Tue, Apr 1, 2014 at 3:28 AM, Ian Clelland iclell...@chromium.org
   wrote:
  
On Mon, Mar 31, 2014 at 4:33 PM, Ian Clelland 
 iclell...@chromium.org
wrote:
   
 On Mon, Mar 31, 2014 at 4:20 PM, Michal Mocny mmo...@chromium.org
 
wrote:

 On Mon, Mar 31, 2014 at 3:39 PM, Ian Clelland 
  iclell...@chromium.org
 wrote:
  This is ugly, though, and is going to get worse over time, and
   become
a
  division between Cordova and any platforms which actually
  implement
the
  File API correctly. I'd like to propose switching the behaviour
 of
  .toURL(), to match .toNativeURL -- returning a webview-usable
 URL
  by
  default -- and implementing some other method or property to get
  the
CDV
  URL when it's necessary.
 

 Everything you've said sounds like its all upside to make the
  switch.
 So
 I'm curious, when would CDV URL be necessary/useful over
  file/content
 urls?


 cdvfile:// URLs would still be necessary when dealing with files
 that
just
 don't *have* an alternate representation. There currently aren't
 any
  of
 those, but we could implement virtual file systems entirely inside
  of a
 plugin, and those would require a cdvfile:// URL to be read.

 I think we'd recommend them when saving URLs to persistent storage,
  if
 there is any chance that the actual files could be moved /
 migrated,
   and
we
 could hide that from the user by giving them a more abstract
  identifier
 than one which specifies a physical location.
 cdvfile://localhost/persistent/my/file.txt might be more durable
 over
time
 than file:///data/data/com.company.package/files/my/file.txt,
 perhaps
 across OS upgrades.

   
Actually, forget all of that.
   
Your question had me looking for reasons to advocate users using
   cdvfile://
URLs, when perhaps none exist. The truth of the matter is this: The
   cdvfile
URL has two parts: the filesystem name, and the full path. Those two
   parts
form a consistent internal representation for all of the types of
 file
   that
the plugin can handle, and so all of the internal / native bits of
 the
   file
plugin use them almost exclusively. We make sure that every FileEntry
  and
DirectoryEntry has those parts, and we only need to turn them into a
  URL
for passing them across the bridge.
   
One day someone may discover a great reason to use deliberately use
   cdvfile
URLs at the application level; until then, they're available, and we
  can
continue to use them internally to simplify the plugin code, enforce
  the
sandboxing, and make everything generally more consistent and
  efficient,
and users shouldn't need to know or care what the URLs in use
 actually
   are.
   
  
   I agree with this as long as the URLs are useable in the WebView (as
 src
   attributes for example). If they're not, I also suggest that we return
  URLs
   that are useable (file:///, content:/// or whatever) by default.
  
   As for filesystems (temp or persistent), I think most developers

Re: config.xml parsing strategy

[Bryan Higgins]

My 2 cents:

- For CLI projects, put assets into merges folder and make use of
platform tag
- The platform is responsible for adding icons and splash screens as part
of the build script

Is there something specific to WP8 which makes this a dity hack?


On Tue, Mar 25, 2014 at 10:38 AM, Axel Nennker ignisvul...@gmail.comwrote:

 Its important to distinguish between project_dir/config.XML and
 runtime/config.XML

 Launcher icon is in the first, app preferences in the second
  Am 25.03.2014 15:32 schrieb Sergey Grebnov (Akvelon) 
 v-seg...@microsoft.com:

  Hi, adding more ppl to our discussion with @purplecabbage
  https://github.com/purplecabbage regarding above
  https://github.com/apache/cordova-cli/pull/145
 
  Working on icons and splash screen support I've encountered with the
  following dilemma. It is easy to add support of the features above as
 part
  of cordova-cli: during prepare step. But ideally (agree w/ Jesse) this
  needs to be handled in the platform repo, since projects can be built
  outside of the cordova-cli and if the property is in the application root
  config.xml it should always be valid. This should be resolved at runtime.
 
  This makes our live more complicated since we can't apply some properties
  in runtime, for example an icon which is showed before the app is even
  started or requires some additional tricks/hacks.  So let's define our
  strategy.
 
 
  1.   If some preference could be applied in Runtime, then it must be
  read from config.xml and applied in runtime.
 
  2.   If not, or requires dirty hacks (for ex: app icon or default
  splash screen) then we should apply such preference during build
 
  a)  Support as part of cordova cli build only OR
 
  b)  Must be implemented as part of platform repo build (applied
 before
  actual build)
 
  a.   On Windows we can use additional cordova/pre_build.bat and
  MSBuild Pre-Build event so it will run automatically before every build.
 
  Any ideas how better to resolve this? How important 2b is?
 
  Thx!
  Sergey
 
 

Re: Platform specific preferences

[Bryan Higgins]

When was that added Andrew? That's a super useful feature that deserves to
be documented!

https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;h=759820


On Mon, Mar 17, 2014 at 10:58 PM, Andrew Grieve agri...@chromium.orgwrote:

 I believe that for projects created with the `cordova` tool, putting tags
 in platform tags already works (they are conditionally copied to the
 derived config.xml within platforms/).


 On Mon, Mar 17, 2014 at 4:44 PM, David Kemp drk...@chromium.org wrote:

  Currently preferences can be specified inside a platform tag in the
  plugin XML. This provides the functionality you describe for a plugin.
  I would suggest if we need to add the same functionality at the app
 level,
  then we do it the same way (put preferences inside a Platform tag)
 
 
 
 
  On Sat, Mar 15, 2014 at 7:33 AM, Sergei Grebnov Home 
  sergei.greb...@gmail.com wrote:
 
   Hi,
  
  
  
   Propose to add optional 'platform' attribute to 'preference' element
   (config.xml) so that we can specify different preferences for different
   platforms. For example, right now there is a preference
   name=SplashScreen
   / (I'm looking on Android code) but I'm not sure single splash screen
   image
   can fit all different platforms (size, image format, etc).
  
  
  
   preference name=BackgroundColor value=#FFD2691E platform=wp8 /
 -
   wp8 only
  
   preference name=SplashScreen value=assets\SplashScreen.png. /
  --
  by
   default applied to all platforms
  
   preference name=SplashScreen
   value=assets\SplashScreenImage.screen-WVGA.jpg. platform=wp8 / -
  wp8
   will use this image; if remove this preference, wp8 will use preference
   above
  
  
  
   Thoughts?
  
  
  
   Thx!
  
   Sergey
  
  
 

Re: Release Managers

[Bryan Higgins]

+1, I'll throw my hat in the ring as well


On Thu, Mar 13, 2014 at 1:13 PM, Steven Gill stevengil...@gmail.com wrote:

 I'm obviously a +1 and highly support this idea.
 On Mar 13, 2014 9:57 AM, Naik, Archana na...@lab126.com wrote:

  +1 I like the idea too. I have never done a release and don't mind being
 a
  guinea pig hereŠ :)
 
  Archana
 
  On 3/13/14 9:44 AM, Michal Mocny mmo...@chromium.org wrote:
 
  +1, like the idea of putting your name into a hat.
  
  How about coaching the first time someone does a release?  Do we
 prefer
  to let the docs stand for themselves?
  
  -Michal
  
  
  On Thu, Mar 13, 2014 at 11:13 AM, Andrew Grieve
  agri...@chromium.orgwrote:
  
   I'd previously brought up the idea of Release Masters, and now after
  the
   recent highlight of our release process by other Apache project
 members,
   I've learned that they are common, and are actually called Release
   Managers.
  
   Their role, in a nutshell, is to take ownership of a release (either
   through delegation, or by doing it themselves).
  
   It's generally not a glorious job, so it would be great if we could
 do a
   bit of a rotation on it:
   - a rotation for tools,
   - a rotation for plugins,
   - a rotation for platforms release.
  
   For tools  plugins, the responsibility is a bit better defined I
 think
  -
   they are responsible for going through the steps in the release
 process.
  
   For platform releases, the release manager wouldn't necessarily be
   responsible for individual platforms, but rather for things like docs,
   website, dist/, and for poking people.
  
  
   As for a rotation, one thought is to write down the names of those
  willing
   in the actual release steps .md files, and then they can plan out how
 to
   schedule themselves from there.
  
   How does this sound?
  
 
 

Re: [Vote] cordova@3.4.0-0.1.3 plugman@0.20.2

[Bryan Higgins]

+1


On Mon, Mar 3, 2014 at 9:48 PM, Ian Clelland iclell...@chromium.org wrote:

 +1

 Tested from dist.apache.org, verified code matching hashes, signature and
 repositories. Verified CB-6151 fix.


 On Mon, Mar 3, 2014 at 4:25 PM, Andrew Grieve agri...@chromium.org
 wrote:

  Please review and vote on this Tools Release.
 
  These archives are identical to cordova@3.4.0-0.1.2 plugman@0.20.1 with
  the
  exception of the fix for CB-6151.
 
  Release issue: https://issues.apache.org/jira/browse/CB-6115
 
  Both tools have been published to dist/dev:
  https://dist.apache.org/repos/dist/dev/cordova/CB-6115/
 
  The packages were published from their corresponding git tags:
  cordova-plugman: 0.20.2 (f1b206d02a)
  cordova-cli: 3.4.0-0.1.3 (0f6250fa3d)
 
  Upon a successful vote I will upload the archives to dist/, publish them
 to
  NPM, and post the corresponding blog post.
 
  Voting will go on for a minimum of 24 hours.
 
  I vote +1.
 
  Note that this time, I have not uploaded them to NPM. Want to avoid
 having
  to bump the version number again. Please install them from dist/ or from
  the git tag.
 

Re: [Vote] cordova@3.4.0-0.1.1 plugman@0.20.0

[Bryan Higgins]

I found another issue which may actually be a show stopper.

Any plugins added prior to adding a platform are not included in that
platform.

This is a regression from 3.4.0-0.1.0

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


On Sun, Mar 2, 2014 at 3:30 PM, Carlos Santana csantan...@gmail.com wrote:

 How do we handle dependencies for cordova-cli and plugman once you put them
 in /dist/ ?

 These tools don't work if user doesn't get/install the dependencies

 I have being looking for more information on these with no luck on what
 should be the best way to handle it for cordova.

 So far I have found two projects struts [1] and maven [2],
 Each one has a document/html explaining for end users what is the
 dependency graph and information about each dependency (Version, License,
 and Location to Get it)

 I know we use npm to install and resolved dependencies but I think we could
 start by documenting for end users what are the dependencies that the
 cordova-cli and plugman need to be able to run.
 Maybe start with a simple table with the dependency graph, version, license
 type (i.e. GPLv2, MIT, Apache 2.0, etc..) and the npm uri and repo uri and
 hash.

 We could also looked into providing a a convenient binary
 cordova-cli-3.4.0.-1.0.1-npmbundle.tgz that includes all the dependencies
 bundled (i.e. npm pack) [3]

 1:
 http://maven.apache.org/wagon/wagon-providers/wagon-ftp/dependencies.html
 2: http://struts.apache.org/release/2.3.x/struts2-core/dependencies.html
 3: https://www.npmjs.org/doc/cli/npm-pack.html






 On Fri, Feb 28, 2014 at 12:13 PM, Andrew Grieve agri...@chromium.org
 wrote:

  Yes, that's my goal.
 
 
  On Fri, Feb 28, 2014 at 11:09 AM, Marcel Kinard cmarc...@gmail.com
  wrote:
 
   To ask the question a bit differently, why is released code not going
 to
   dist? Additional channels are fine, but the channels should always
  include
   dist, right?
  
   My intention in asking this question is to not force a vote, but for
   consumers to find all Apache-released software on dist. Or do I
   misunderstand the role of dist? I'm looking at the sections Where do
   releases go and Where can we host public (GA) releases of
   http://www.apache.org/dev/release
  
   Or are the tools and plugins not considered released code?
  
   (I can hear the moans already, just trying to keep us honest.)
  
   Andrew, do I understand that you'll be posting tools and plugins to
 dist?
  
   On Feb 27, 2014, at 11:51 AM, Brian LeRoux b...@brian.io wrote:
  
We do not have to vote on code not on /dist.
On Feb 27, 2014 8:47 AM, Andrew Grieve agri...@chromium.org
 wrote:
  
  
 



 --
 Carlos Santana
 csantan...@gmail.com

Re: enabling cordova-cli and plugman npm modules with shrinkwrap?

[Bryan Higgins]

+1 Great suggestion Carlos.


On Mon, Mar 3, 2014 at 2:44 PM, Shazron shaz...@gmail.com wrote:

 Like it, it makes sense


 On Sun, Mar 2, 2014 at 9:17 AM, Carlos Santana csantan...@gmail.com
 wrote:

  I want to ask if there any issues using npm shrinkwrap when rc testing
 and
  publishing to npm registry?
 
  I opened a jira item here for more details including benefits to cordova
  project:
  https://issues.apache.org/jira/browse/CB-6147
 
  Background Info:
  https://www.npmjs.org/doc/cli/npm-shrinkwrap.html
 
 
 http://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shrinkwrap
 
 
  --
  Carlos Santana
  csantan...@gmail.com
 

Re: [Vote] cordova@3.4.0-0.1.2 plugman@0.20.1

[Bryan Higgins]

I found the following regression while testing this release against BB10.

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

I'm not familiar enough with the changes in plugman to have an opinion on
whether this outweighs the benefits introduced, so I won't vote either way.

Otherwise project creation, adding/removing plugins and build/run all
worked well.


On Fri, Feb 28, 2014 at 4:05 PM, Ian Clelland iclell...@chromium.orgwrote:

 +1

 Checked signatures and hashes. Checked diffs (not too crude a tool) against
 the corresponding tags in the repos.
 Installed both plugman and CLI; both appear to be working correctly,
 building projects, adding and removing plugins, building and deploying to
 Android devices.


 On Fri, Feb 28, 2014 at 4:00 PM, Joe Schaefer joe_schae...@yahoo.com
 wrote:

  If diff is a little too crude for this purpose I encourage you to
  take a look at
 
 
 
 https://svn.apache.org/repos/private/committers/tools/releases/compare_dirs.pl
 
  The way you'd use it is to unzip the two archive files into separate
 paths
  and invoke this script on those paths.  It takes a list of filenames to
  skip as arguments, but those could probably be scripted away into a
 wrapper
  call around it.
 
 
 
 
  On Friday, February 28, 2014 3:50 PM, Andrew Grieve 
 agri...@chromium.org
  wrote:
 
  On Fri, Feb 28, 2014 at 3:37 PM, Andrew Grieve agri...@chromium.org
  wrote:
  
   Note that since we can't re-upload to NPM with the same versions, I've
   bumped the version since my first attempt.
  
   If you'd like to verify the files on dist/, you can now clone the repo
  via:
   ./cordova-coho/coho repo-clone -r dist/dev
  
   And check the hashes  signature with:
   ./cordova-coho/coho verify-archive cordova-dist-dev/$JIRA/*.zip
  
   There's no logic there to check the actual contents of the zip yet
  though
   (if someone feels like adding this, please do!)
  
  Actually, you could just build the archive and use diff to verify the
  contents:
  ./cordova-coho/coho create-archive -r plugman -r cli --no-sign --dest .
  diff plugman*.zip cordova-dist-dev/CB-6115/plugman*.zip
  diff cordova*.zip cordova-dist-dev/CB-6115/cordova*.zip
  
  
  
  
  
  
   Please review and vote on the release of cordova@3.4.0-0.1.2
   plugman@0.20.1.
  
   Release issue: https://issues.apache.org/jira/browse/CB-6115
  
   Both cordova and plugman have been uploaded to npm with the rc tag:
   npm install -g cordova@rc
   npm install -g plugman@rc
  
   They have also been published to dist:
   https://dist.apache.org/repos/dist/dev/cordova/CB-6115/
  
   The packages were published from their corresponding git tags:
   plugman: 0.20.1 (6a827cc28167a31f9d3c1196303b0910ad87ec5a)
   cli: 3.4.0-0.1.2 (d9097de6b00a4ff39e3250bac36d343ff23294ad)
  
   Upon a successful vote, I will tag the releases as latest on NPM and
   post the corresponding blog post.
  
   Voting will go on for 48 hours.
  
  
  
  
 

Re: [VOTE] Cordova 2.8.1

[Bryan Higgins]

+1


On Tue, Feb 25, 2014 at 4:55 PM, RUDD, Brett brettr...@gmail.com wrote:

 +1

 On Feb 25, 2014, at 13:21, Steven Gill stevengil...@gmail.com wrote:

  2.8.0 did. Figured might as well do the point release too
  On Feb 25, 2014 1:18 PM, Joe Bowser bows...@gmail.com wrote:
 
  +1 - This release had a vote, didn't it?
 
  On Tue, Feb 25, 2014 at 12:20 PM, Lorin Beer lorin.beer@gmail.com
  wrote:
  +1
 
 
  On Tue, Feb 25, 2014 at 12:03 PM, Steven Gill stevengil...@gmail.com
  wrote:
 
  Please review and vote on our past release of Cordova 2.8.1.
 
  You can find the src + asc + md5 + sha at the following links:
  * http://archive.apache.org/dist/cordova/cordova-2.8.1-src.zip
  * http://archive.apache.org/dist/cordova/cordova-2.8.1-src.zip.asc
  * http://archive.apache.org/dist/cordova/cordova-2.8.1-src.zip.md5
  * http://archive.apache.org/dist/cordova/cordova-2.8.1-src.zip.sha
 
  The 2.8.1 tag was only applied to Android
 
 
 
 http://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=shortlog;h=refs/tags/2.8.1
  d8c755b95a85de95c51768a271aa2747bb5467b9 refs/tags/2.8.1
 
  The 2.8.0 tag was used for other platforms
 
 
 
 http://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=shortlog;h=refs/tags/2.8.0
  f93f7a5bad8b7f9d141852c8b1f369a262f0389e refs/tags/2.8.0
 
 
 
 http://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=shortlog;h=refs/tags/2.8.0
  a297ff557b93c30427a113af80620221c8a74f40 refs/tags/2.8.0
 
 
 
 http://git-wip-us.apache.org/repos/asf?p=cordova-windows.git;a=shortlog;h=refs/tags/2.8.0
  326130a182e5cd2d391e942efdf961cc6fa34040 refs/tags/2.8.0
 
 
 
 http://git-wip-us.apache.org/repos/asf?p=cordova-wp8.git;a=shortlog;h=refs/tags/2.8.0
  9176a0238c26ea1fd5edfe2e2b052607aca1b9ac refs/tags/2.8.0
 
 
 
 http://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=shortlog;h=refs/tags/2.8.0
  a2f158653f533ebbb5dfbfe136bfdf9e1a57f01c refs/tags/2.8.0
 
 
 
 http://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/tags/2.8.0
  6208c9593a0a472f3e04168c9d237a3121329c1a refs/tags/2.8.0
 
 
 
 http://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=shortlog;h=refs/tags/2.8.0
  4fdfaad8fed1ea52bea5401ee1e1d2099d94f446 refs/tags/2.8.0
 
 
 
 http://git-wip-us.apache.org/repos/asf?p=cordova-app-hello-world.git;a=shortlog;h=refs/tags/2.8.0
  366f9843eb3d2172986d18cf370323ddd35117b8 refs/tags/2.8.0
 
 
 
 http://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=shortlog;h=refs/tags/2.8.0
  c222b586d286d2dd3a7ba67259d05d5f60e51d8f refs/tags/2.8.0
 
  Voting will go on for 48 hours.
 
 

Re: BlackBerry 10 - config.xml iicon entries are not filtered for gap:platform

[Bryan Higgins]

I'd like to see config.xml have a platform tag similar to plugin.xml.
Neither Cordova nor BlackBerry native tools should understand PhoneGap
attributes.


On Thu, Feb 20, 2014 at 5:26 PM, Don Coleman don.cole...@gmail.com wrote:

 I have a project that uses PhoneGap build for iOS and Android, and uses
 Cordova to build for BlackBerry 10.

 The icons are specified in config.xml

 icon src=icon.png /
 icon src=res/icon/android/icon-36-ldpi.png   gap:platform=android
gap:density=ldpi /
 icon src=res/icon/android/icon-48-mdpi.png   gap:platform=android
gap:density=mdpi /
 icon src=res/icon/android/icon-72-hdpi.png   gap:platform=android
gap:density=hdpi /
 icon src=res/icon/android/icon-96-xhdpi.png  gap:platform=android
gap:density=xhdpi /
 icon src=res/icon/blackberry/icon-80.png
 gap:platform=blackberry /
 icon src=res/icon/blackberry/icon-80.png
 gap:platform=blackberry gap:state=hover/
 !-- ... --

 When the bar file is built, the Entry-Point-Icon Manifest entry is
 incorrect

 $ unzip -p platforms/blackberry10/build/device/bb10app.bar
 META-INF/MANIFEST.MF | grep Entry

 Entry-Point: WEBWORKS_VERSION=2.0.0 CONSOLE_MODE=slog2
 CASCADES_THEME=default app/native/wwe
 Entry-Point-Type: Qnx/WebKit
 Entry-Point-Icon:

 {72x72}native/icon.png:{36x36}native/res/icon/android/icon-36-ldpi.png:{48x48}native/res/icon/android/icon-48-mdpi.png:{72x72}native/res/icon/android/icon-72-hdpi.png:{96x96}native/res/icon/android/icon-96-xhdpi.png:{80x80}native/res/icon/blackberry/icon-80.png:{57x57}n
 Entry-Point-Orientation: auto


 The app looks deploys OK locally and passes blackberry-barchecker, but
 BlackBerry Enterprise Server rejected the app due to this entry.

 I fixed the problem by preprocessing the config.xml before the blackberry10
 build.

 Entry-Point: WEBWORKS_VERSION=2.0.0 CASCADES_THEME=default app/native/wwe
 Entry-Point-Type: Qnx/WebKit
 Entry-Point-Icon: native/res/icon/blackberry/icon-80.png
 Entry-Point-Orientation: auto


 Is this a problem that Cordova should handle? Or is it a problem with the
 blackberry-nativepackager?

Re: Cordova 3.3.1-0.4.2 and BlackBerry 10 can't deploy to connected device

[Bryan Higgins]

Hi Don,

CLI 3.3.1-0.4.2 changed the run command so that --device is no longer
passed down to the platform scripts. BB10 relied upon this to start device
detection. I did not notice any communication about this on the list.
Perhaps the implementor didn't know enough about bb10 to know this would be
a problem.

For 3.4, I've updated cordova-blackberry to make this the default
behaviour. In 3.3.1-0.4.2, you can work around by passing in --device.

I'll look into the issue you're seeing with release builds.

Thanks,
Bryan


On Tue, Feb 18, 2014 at 8:10 PM, Don Coleman don.cole...@gmail.com wrote:

 It looks like 3.3.1-0.4.2 has more problems

 * release builds don't get the version number from config.xml
 * release builds don't get use the launch icon from config.xml

 Is anyone using 3.4 with BB10?


 On Tue, Feb 18, 2014 at 6:02 PM, Don Coleman don.cole...@gmail.com
 wrote:

  Cordova 3.3.1-0.4.2 can't find an deploy to locally attached devices.
 
  $ cordova run blackberry10 --devicepass ff
 
  Generating config.xml from defaults for platform blackberry10
 
  Preparing blackberry10 project
 
  Running app on platform blackberry10 via command
  /Users/.../platforms/blackberry10/cordova/run --devicepass 19034
 
  Error: An error occurred while running the blackberry10 project.No
  target exists, to add that target please run: target add name ip [-t
 |
  --type device | simulator] [-p password] [--pin devicepin]
 
  Windows 7 with 3.3.1-0.4.2 does the same thing.
 
  Downgrading back to 3.3.1-0.1.2 fixes the problem on OS X
  I'm hoping this is a bug and not intentional behavior? (Not a fan of
  target add)
 

Re: Cordova 3.3.1-0.4.2 and BlackBerry 10 can't deploy to connected device

[Bryan Higgins]

I could not reproduce your release builds issue on 3.3.1-0.4.2. Could you
please file a JIRA with specifics?


On Wed, Feb 19, 2014 at 8:21 AM, Bryan Higgins br...@bryanhiggins.netwrote:

 Hi Don,

 CLI 3.3.1-0.4.2 changed the run command so that --device is no longer
 passed down to the platform scripts. BB10 relied upon this to start device
 detection. I did not notice any communication about this on the list.
 Perhaps the implementor didn't know enough about bb10 to know this would be
 a problem.

 For 3.4, I've updated cordova-blackberry to make this the default
 behaviour. In 3.3.1-0.4.2, you can work around by passing in --device.

 I'll look into the issue you're seeing with release builds.

 Thanks,
 Bryan


 On Tue, Feb 18, 2014 at 8:10 PM, Don Coleman don.cole...@gmail.comwrote:

 It looks like 3.3.1-0.4.2 has more problems

 * release builds don't get the version number from config.xml
 * release builds don't get use the launch icon from config.xml

 Is anyone using 3.4 with BB10?


 On Tue, Feb 18, 2014 at 6:02 PM, Don Coleman don.cole...@gmail.com
 wrote:

  Cordova 3.3.1-0.4.2 can't find an deploy to locally attached devices.
 
  $ cordova run blackberry10 --devicepass ff
 
  Generating config.xml from defaults for platform blackberry10
 
  Preparing blackberry10 project
 
  Running app on platform blackberry10 via command
  /Users/.../platforms/blackberry10/cordova/run --devicepass 19034
 
  Error: An error occurred while running the blackberry10 project.No
  target exists, to add that target please run: target add name ip
 [-t |
  --type device | simulator] [-p password] [--pin devicepin]
 
  Windows 7 with 3.3.1-0.4.2 does the same thing.
 
  Downgrading back to 3.3.1-0.1.2 fixes the problem on OS X
  I'm hoping this is a bug and not intentional behavior? (Not a fan of
  target add)
 

Re: 3.3.1-0.4.1 reverts blackberry10 to 3.3.0

[Bryan Higgins]

Thanks Steve! Looks good.


On Tue, Feb 11, 2014 at 4:50 PM, Steven Gill stevengil...@gmail.com wrote:

 Shoot!

 I just fixed this right now.

 In regards to branching policy, I think the easiest way to fix this, which
 I should have done originally for the revert, is to checkout the
 3.3.1-0.4.1 tag, make the modification, commit, tag 3.3.1-0.4.2 and npm
 publish. Master stays ready for 3.4 release and bb fix is back out there as
 it should have been in the first place (sorry about that).

 I just tried this out and it works. Let me know if you see anything wrong
 with it. npm install cordova should get 3.3.1-0.4.2 now.


 On Tue, Feb 11, 2014 at 12:26 PM, Bryan Higgins br...@bryanhiggins.net
 wrote:

  The 3.3.1 version of bb10 was inadvertently reverted to 3.3.0 [1][2]
 
  I'd like to clean this up before 3.4 hits as 3.3.1 fixed a critical bug
 on
  Windows machines.
 
  I think this means I'll need to revert the 3.4.0 version changes, fix
  platforms.js, tag, publish, then put the 3.4.0 version changes back in. I
  will do so tomorrow unless there are objections...
 
  Perhaps this is a reason to revisit the branching policy? Even a small
  branch just for publishing the RC would have avoided this.
 
  [1]
 
 
 https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=blobdiff;f=platforms.js;h=2e23480
  [2]
 
 
 https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=blobdiff;f=platforms.js;h=be7f2cb
 

3.3.1-0.4.1 reverts blackberry10 to 3.3.0

[Bryan Higgins]

The 3.3.1 version of bb10 was inadvertently reverted to 3.3.0 [1][2]

I'd like to clean this up before 3.4 hits as 3.3.1 fixed a critical bug on
Windows machines.

I think this means I'll need to revert the 3.4.0 version changes, fix
platforms.js, tag, publish, then put the 3.4.0 version changes back in. I
will do so tomorrow unless there are objections...

Perhaps this is a reason to revisit the branching policy? Even a small
branch just for publishing the RC would have avoided this.

[1]
https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=blobdiff;f=platforms.js;h=2e23480
[2]
https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=blobdiff;f=platforms.js;h=be7f2cb

Re: Introductory Developer Email

[Bryan Higgins]

Welcome Josh!


On Tue, Jan 7, 2014 at 9:19 AM, Michal Mocny mmo...@chromium.org wrote:

 Ahoy Josh!

 Any specific parts of cordova that interest you most?


 On Mon, Jan 6, 2014 at 10:36 PM, Andrew Grieve agri...@chromium.org
 wrote:

  Awesome! Welcome to the team!
 
 
  On Mon, Jan 6, 2014 at 3:40 PM, Brian LeRoux b...@brian.io wrote:
 
   Right on, welcome to the fray Josh.
  
  
   On Mon, Jan 6, 2014 at 3:31 PM, Anis KADRI anis.ka...@gmail.com
 wrote:
  
Welcome Josh!
   
   
On Mon, Jan 6, 2014 at 9:20 AM, Josh Bavari jbav...@gmail.com
 wrote:
   
 Hello fellow Cordova Devs,

 I have been using PhoneGap / Cordova for about the last few years
 and
love
 that the project is ever evolving. I would like to help contribute
 to
   the
 Cordova project as well to help give back some of what was freely
  given
to
 myself.

 Some of my hobbies include mobile development (im guessing you
  already
knew
 hybrid apps), coding in Ruby and Javascript, process automation,
 and
 speaking / mentoring others.

 I hope to be chatting with many of you and contributing on issues
  that
   I
 myself find or that others may have an urgent priority for.

 Thanks, and may we build a better future.


 --
 Clear thoughts produce clear results.
 Josh Bavari
 Application Developer
 Phone: 405-509-9448
 Cell: 405-812-0496
 Email: jbav...@gmail.com

   
  
 

Re: Point Release for BB

[Bryan Higgins]

We decided to revert the commit which broke init.bat rather than apply the
full fix now.

BlackBerry is tagged at 3.3.1.

Should CLI get bumped to 3.3.1 or 3.3.0-0.2.0 ?


On Tue, Dec 17, 2013 at 10:57 PM, Josh Soref jso...@blackberry.com wrote:

 Andrew wrote:
  How's this going?
 
 It took a bit more than I had expected, and testing it took longer, but we
 have a fix and it's tested. I assume it will land tomorrow morning.
 -
 This transmission (including any attachments) may contain confidential
 information, privileged material (including material protected by the
 solicitor-client or other applicable privileges), or constitute non-public
 information. Any use of this information by anyone other than the intended
 recipient is prohibited. If you have received this transmission in error,
 please immediately reply to the sender and delete this information from
 your system. Use, dissemination, distribution, or reproduction of this
 transmission by unintended recipients is not authorized and may be unlawful.

Re: Point Release for BB

[Bryan Higgins]

Done!


On Thu, Dec 19, 2013 at 11:57 AM, Andrew Grieve agri...@chromium.orgwrote:

 3.3.1-0.1.1 makes sense to me since it's a change to the platforms.js file.

 Since there's a couple of bugfixes since it was released, might want to
 bump both numbers:
 3.3.1-0.1.2





 On Thu, Dec 19, 2013 at 11:18 AM, Bryan Higgins br...@bryanhiggins.net
 wrote:

  We decided to revert the commit which broke init.bat rather than apply
 the
  full fix now.
 
  BlackBerry is tagged at 3.3.1.
 
  Should CLI get bumped to 3.3.1 or 3.3.0-0.2.0 ?
 
 
  On Tue, Dec 17, 2013 at 10:57 PM, Josh Soref jso...@blackberry.com
  wrote:
 
   Andrew wrote:
How's this going?
  
   It took a bit more than I had expected, and testing it took longer, but
  we
   have a fix and it's tested. I assume it will land tomorrow morning.
   -
   This transmission (including any attachments) may contain confidential
   information, privileged material (including material protected by the
   solicitor-client or other applicable privileges), or constitute
  non-public
   information. Any use of this information by anyone other than the
  intended
   recipient is prohibited. If you have received this transmission in
 error,
   please immediately reply to the sender and delete this information from
   your system. Use, dissemination, distribution, or reproduction of this
   transmission by unintended recipients is not authorized and may be
  unlawful.
  
 

Point Release for BB

[Bryan Higgins]

We would like to do a point release this afternoon for BlackBerry to fix
CB-5660.

Lesson learned: Use delayed expansion in Windows batch files, otherwise
user's environment variables can end up being parsed as part of the script.
Ugh!

Platform update warning

[Bryan Higgins]

How does everyone feel about adding a warning message when the platform
version is older than CLI version?

I've talked to some users recently who had no idea the update command
existed. They assumed that by updating via npm, their project would get all
of the bug fixes.

Re: Platform update warning

[Bryan Higgins]

Yep, that's not a bad plan:

Cordova updated to 3.x. To update your project platform scripts, run
'cordova platform update' from the project directory.

I was thinking of specifically calling out the platforms which need
updating on first run of cordova, but that would require us to keep track
of when the warning was shown, probably by writing to config.json or
another file in .cordova.




On Mon, Dec 16, 2013 at 11:02 AM, Andrew Grieve agri...@chromium.orgwrote:

 I wouldn't want to show the warning on every single command forevermore,
 but definitely a good idea to slip it in there somewhere. Maybe we could
 show it when they do an npm update?


 On Mon, Dec 16, 2013 at 9:13 AM, Bryan Higgins br...@bryanhiggins.net
 wrote:

  How does everyone feel about adding a warning message when the platform
  version is older than CLI version?
 
  I've talked to some users recently who had no idea the update command
  existed. They assumed that by updating via npm, their project would get
 all
  of the bug fixes.
 

Re: 3.3 Blog Post (Please Review)

[Bryan Higgins]

Notes for BB10

[CB-5434] Windows: Always use USERPROFILE for home directory
[CB-5443] Windows: Handle installed 64 bit Java
[CB-5468] Improve config.xml encoding handling
[CB-5509] Remove ability to set default target (since device detection
is now used)
[CB-5510] Update response codes for plugin success/fail
[CB-5413] Device detection - iterate through all 169.254.x networks
[CB-5317] Move signing warn logic to build/run scripts
[CB-5258] Use exit library for process.exit




On Mon, Dec 16, 2013 at 3:05 PM, Andrew Grieve agri...@chromium.org wrote:

 I've added release notes for Android, iOS, CLI. If you want your platform
 to have release notes in this post, then please add them below.



 ---
 layout: post
 author:
 name: Andrew Grieve
 url: https://twitter.com/GrieveAndrew
 title:  Apache Cordova 3.3.0
 categories: announcements
 tags: news releases
 ---

 On Friday, `Cordova 3.3` went live on npm. Woohoo!

 This release brings with it initial support for Ubuntu Touch as well as
 Fire OS!

 To upgrade: (replace `android` with the platform you want to update):

 npm install -g cordova
 cd my_project
 cordova platform update android

 For non-CLI projects or for pre-3.0 projects, refer to the [upgrade
 guides](
 http://cordova.apache.org/docs/en/3.3.0/guide_platforms_index.md.html).

 !--more--

 ## What's new in Android

 41 commits from 11 authors. Highlights include:

 * CB-5481 Fix for Cordova trying to get config.xml from the wrong namespace
 * CB-5487 Enable Remote Debugging when your Android app is debuggable.
 * CB-5445 Adding onScrollChanged and the ScrollEvent object
 * CB-5422 Don't require JAVA_HOME to be defined
 * CB-5490 Add javadoc target to ant script
 * CB-5471 Deprecated DroidGap class
 * CB-5255 Prefer Google API targets over android-## targets when building.
 * CB-5232 Change create script to use Cordova as a Library Project instead
 of a .jar
 * CB-5302 Massive movement to get tests working again
 * CB-4996 Fix paths with spaces while launching on emulator and device
 * CB-5209 Cannot build Android app if project path contains spaces

 ## What's new in iOS

 * No significant Changes

 ## What's new in Windows Phone 7  8


 ## What's new in Windows 8


 ## What's new in BlackBerry 10


 ## What's new in FirefoxOS


 ## What's new in Cordova-CLI

 * CB-5347 Handle dangling platform symlink in cordova platform add
 * Added deprecation notice about wp7
 * Updated plugman version to 0.17.0
   * CB-5238 Adds support on iOS for framework src=... custom=true /
 * CB-5573 relies on stderr content and error codes to detect a problem with
 xcode installation.
 * CB-4382 Pass cli arguments to project-level hooks
 * CB-5362 blackberry parser: support local cordova-blackberry
 * CB-5345 Add pre_package event for windows8 parser.

 ## Plugin versions tested with this release

 * cordova-plugin-battery-status: 0.2.5
 * cordova-plugin-camera: 0.2.5
 * cordova-plugin-console: 0.2.5
 * cordova-plugin-contacts: 0.2.6
 * cordova-plugin-device: 0.2.5
 * cordova-plugin-device-motion: 0.2.4
 * cordova-plugin-device-orientation: 0.3.3
 * cordova-plugin-dialogs: 0.2.4
 * cordova-plugin-file: 0.2.5
 * cordova-plugin-file-transfer: 0.4.0
 * cordova-plugin-geolocation: 0.3.4
 * cordova-plugin-globalization: 0.2.4
 * cordova-plugin-inappbrowser: 0.2.5
 * cordova-plugin-media: 0.2.6
 * cordova-plugin-media-capture: 0.2.5
 * cordova-plugin-network-information: 0.2.5
 * cordova-plugin-splashscreen: 0.2.5
 * cordova-plugin-vibration: 0.3.5

Re: plugins.cordova.io: UX redesign

[Bryan Higgins]

Those comps look great Joni! Nice work!

The details page needs a way to view prior versions.


On Thu, Dec 12, 2013 at 8:38 AM, James Jong wjamesj...@gmail.com wrote:

 UX looks great!!  Thanks for the efforts!

 2. For search, perhaps the ability to add/remove filters?

 +1 to making it responsive

 -James Jong

 On Dec 11, 2013, at 10:26 PM, Joni Rustulka j...@adobe.com wrote:

  Hi all,
 
  I'm Joni. I work at Adobe as a UX designer on the PhoneGap team, and I
 have recently thrown some time at redesigning the
 http://plugins.cordova.io site. I'm looking for feedback prior to
 implementation - your thoughts are appreciated.
 
  The main screens that have been reworked are as follows:
 
 
   1.  Home (http://cl.ly/image/2n3l1N0Z0g0w)
  The primary goal for the site is to help users find the plugins they
 need. As such, the main focus is on search/findability.
 
   2.  Search Results (http://cl.ly/image/0c3X3T1E1L0j)
  Upon search for a plugin, the user is returned results. The user can
 filter to include only desired platforms (http://cl.ly/image/3W2f321I211r),
 and the results table can be sorted by number of downloads, or plugin ID.
 
   3.  Plugin Details (http://cl.ly/image/2n1p2s3E0a2t)
  The details screen intends to provide all of the necessary information
 on a plugin.
  ** From what I understand, one piece of information that may be missing
 from this screen is Installation Instructions. This being, config.xml
 feature tags. Is this something that you guys plan to automate, or should
 we be telling plugin authors to put this information in their Read Me?
 Please advise.
 
  Further, we do intend to make this a responsive site - so it will be
 easily viewed on smaller screen sizes.
 
  Thanks for your input,
  -joni
 
 
  PS - big thanks and kudos to Yohei for putting together the pluggy robot!
 
 

Re: Cordova CLI minor update

[Bryan Higgins]

Michal - how goes CB-5338? I'd love to get a point release out before the
weekend.


On Thu, Nov 28, 2013 at 3:16 PM, Bryan Higgins br...@bryanhiggins.netwrote:

 I've put a fix in for BB, which unfortunately has to contain custom code
 paths [1].

 The lazy load was putting files under blackberry10 sub-folder, when they
 have always lived directly in ~/.cordova/lib/blackberry10/cordova/VERSION

 I'm not sure why the windows platforms prefer to have the extra
 sub-directory, but we can't change the location for bb10 without also
 updating the platform version in platforms.js. There are active users who
 have already downloaded the 3.2 lib. Hopefully not many have started
 cleanly on 3.2.0-0.2.0, which would put them in a bad state.

 [1]
 https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=commit;h=f7a35b3ca8a8b787fbbe01aebed286802451b64a


 On Thu, Nov 28, 2013 at 10:52 AM, Andrew Grieve agri...@chromium.orgwrote:

 On Thu, Nov 28, 2013 at 10:05 AM, Michal Mocny mmo...@chromium.org
 wrote:

  If we are going to land another CLI point release, I suggest we wait for
  CB-5338 as well to properly fix the android API version bump to 18 as we
  planned for 3.2.  That should land soon/today.
 
  -Michal
 
 
  On Thu, Nov 28, 2013 at 10:00 AM, Bryan Higgins br...@bryanhiggins.net
  wrote:
 
   This update breaks BB10 badly.
  
   There was a change made to attempt standardizing platforms in
  sub-folders.
   I asked yesterday if this had been tested on BB10  The answer was no.
  When
   I found some time to test it out (just now), it had already been
 merged
   into master and released to NPM.
  
   Perhaps if the commit messages had JIRA ids and something more
  descriptive
   than merging master from x, we'd have a clue about what we're
   releasing...
  
  
   On Wed, Nov 27, 2013 at 4:26 PM, Lorin Beer lorin.beer@gmail.com
   wrote:
  
Michael and I released another version of the Cordova CLI this
 morning.
   
This is a minor version bump, and includes a commit to fix a
 blocking
   issue
for projects that consume the Cordova CLI as a library.
 

 What is the issue? Is there a JIRA for it?

 Sounds like it's unlikely worse than having BB completely broken. I'd like
 someone else to make the call since I'm still catching up on things, but
 sounds like we may want to roll back this point release until BB is fixed.
 E.g., make it not latest tag in npm.


   
This was tested on OSX and Windows before the release, and should
 not
affect the Cordova CLI at all.
   
In the future, the list will be notified prior before even a minor
   release
like this.
 

 This was already the documented procedure. Bad call it seems :(.



   
- Lorin
   
  
 

Re: Cordova CLI minor update

[Bryan Higgins]

Created CB-5507

I'll push it out this afternoon if there are no objections.


On Fri, Nov 29, 2013 at 9:30 AM, Michal Mocny mmo...@chromium.org wrote:

 It landed, sorry I forgot to close the issue.
  (cordova-android 42f4d49fc30ca37fb22309b92f104c2336f70c3f)


 On Fri, Nov 29, 2013 at 8:46 AM, Bryan Higgins br...@bryanhiggins.net
 wrote:

  Michal - how goes CB-5338? I'd love to get a point release out before the
  weekend.
 
 
  On Thu, Nov 28, 2013 at 3:16 PM, Bryan Higgins br...@bryanhiggins.net
  wrote:
 
   I've put a fix in for BB, which unfortunately has to contain custom
 code
   paths [1].
  
   The lazy load was putting files under blackberry10 sub-folder, when
 they
   have always lived directly in
  ~/.cordova/lib/blackberry10/cordova/VERSION
  
   I'm not sure why the windows platforms prefer to have the extra
   sub-directory, but we can't change the location for bb10 without also
   updating the platform version in platforms.js. There are active users
 who
   have already downloaded the 3.2 lib. Hopefully not many have started
   cleanly on 3.2.0-0.2.0, which would put them in a bad state.
  
   [1]
  
 
 https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=commit;h=f7a35b3ca8a8b787fbbe01aebed286802451b64a
  
  
   On Thu, Nov 28, 2013 at 10:52 AM, Andrew Grieve agri...@chromium.org
  wrote:
  
   On Thu, Nov 28, 2013 at 10:05 AM, Michal Mocny mmo...@chromium.org
   wrote:
  
If we are going to land another CLI point release, I suggest we wait
  for
CB-5338 as well to properly fix the android API version bump to 18
 as
  we
planned for 3.2.  That should land soon/today.
   
-Michal
   
   
On Thu, Nov 28, 2013 at 10:00 AM, Bryan Higgins 
  br...@bryanhiggins.net
wrote:
   
 This update breaks BB10 badly.

 There was a change made to attempt standardizing platforms in
sub-folders.
 I asked yesterday if this had been tested on BB10  The answer was
  no.
When
 I found some time to test it out (just now), it had already been
   merged
 into master and released to NPM.

 Perhaps if the commit messages had JIRA ids and something more
descriptive
 than merging master from x, we'd have a clue about what we're
 releasing...


 On Wed, Nov 27, 2013 at 4:26 PM, Lorin Beer 
  lorin.beer@gmail.com
 wrote:

  Michael and I released another version of the Cordova CLI this
   morning.
 
  This is a minor version bump, and includes a commit to fix a
   blocking
 issue
  for projects that consume the Cordova CLI as a library.
   
  
   What is the issue? Is there a JIRA for it?
  
   Sounds like it's unlikely worse than having BB completely broken. I'd
  like
   someone else to make the call since I'm still catching up on things,
 but
   sounds like we may want to roll back this point release until BB is
  fixed.
   E.g., make it not latest tag in npm.
  
  
 
  This was tested on OSX and Windows before the release, and
 should
   not
  affect the Cordova CLI at all.
 
  In the future, the list will be notified prior before even a
 minor
 release
  like this.
   
  
   This was already the documented procedure. Bad call it seems :(.
  
  
  
 
  - Lorin
 

   
  
  
  
 

Re: Cordova CLI minor update

[Bryan Higgins]

Could someone please add me as an owner so I can push out the update?


On Fri, Nov 29, 2013 at 9:46 AM, Bryan Higgins br...@bryanhiggins.netwrote:

 Created CB-5507

 I'll push it out this afternoon if there are no objections.


 On Fri, Nov 29, 2013 at 9:30 AM, Michal Mocny mmo...@chromium.org wrote:

 It landed, sorry I forgot to close the issue.
  (cordova-android 42f4d49fc30ca37fb22309b92f104c2336f70c3f)


 On Fri, Nov 29, 2013 at 8:46 AM, Bryan Higgins br...@bryanhiggins.net
 wrote:

  Michal - how goes CB-5338? I'd love to get a point release out before
 the
  weekend.
 
 
  On Thu, Nov 28, 2013 at 3:16 PM, Bryan Higgins br...@bryanhiggins.net
  wrote:
 
   I've put a fix in for BB, which unfortunately has to contain custom
 code
   paths [1].
  
   The lazy load was putting files under blackberry10 sub-folder, when
 they
   have always lived directly in
  ~/.cordova/lib/blackberry10/cordova/VERSION
  
   I'm not sure why the windows platforms prefer to have the extra
   sub-directory, but we can't change the location for bb10 without also
   updating the platform version in platforms.js. There are active users
 who
   have already downloaded the 3.2 lib. Hopefully not many have started
   cleanly on 3.2.0-0.2.0, which would put them in a bad state.
  
   [1]
  
 
 https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=commit;h=f7a35b3ca8a8b787fbbe01aebed286802451b64a
  
  
   On Thu, Nov 28, 2013 at 10:52 AM, Andrew Grieve agri...@chromium.org
  wrote:
  
   On Thu, Nov 28, 2013 at 10:05 AM, Michal Mocny mmo...@chromium.org
   wrote:
  
If we are going to land another CLI point release, I suggest we
 wait
  for
CB-5338 as well to properly fix the android API version bump to 18
 as
  we
planned for 3.2.  That should land soon/today.
   
-Michal
   
   
On Thu, Nov 28, 2013 at 10:00 AM, Bryan Higgins 
  br...@bryanhiggins.net
wrote:
   
 This update breaks BB10 badly.

 There was a change made to attempt standardizing platforms in
sub-folders.
 I asked yesterday if this had been tested on BB10  The answer was
  no.
When
 I found some time to test it out (just now), it had already been
   merged
 into master and released to NPM.

 Perhaps if the commit messages had JIRA ids and something more
descriptive
 than merging master from x, we'd have a clue about what we're
 releasing...


 On Wed, Nov 27, 2013 at 4:26 PM, Lorin Beer 
  lorin.beer@gmail.com
 wrote:

  Michael and I released another version of the Cordova CLI this
   morning.
 
  This is a minor version bump, and includes a commit to fix a
   blocking
 issue
  for projects that consume the Cordova CLI as a library.
   
  
   What is the issue? Is there a JIRA for it?
  
   Sounds like it's unlikely worse than having BB completely broken. I'd
  like
   someone else to make the call since I'm still catching up on things,
 but
   sounds like we may want to roll back this point release until BB is
  fixed.
   E.g., make it not latest tag in npm.
  
  
 
  This was tested on OSX and Windows before the release, and
 should
   not
  affect the Cordova CLI at all.
 
  In the future, the list will be notified prior before even a
 minor
 release
  like this.
   
  
   This was already the documented procedure. Bad call it seems :(.
  
  
  
 
  - Lorin
 

   
  
  
  
 

Re: Cordova CLI minor update

[Bryan Higgins]

Yes, please


On Fri, Nov 29, 2013 at 1:26 PM, Michal Mocny mmo...@chromium.org wrote:

 Using br...@bryanhiggins.net ?


 On Fri, Nov 29, 2013 at 1:21 PM, Bryan Higgins br...@bryanhiggins.net
 wrote:

  Could someone please add me as an owner so I can push out the update?
 
 
  On Fri, Nov 29, 2013 at 9:46 AM, Bryan Higgins br...@bryanhiggins.net
  wrote:
 
   Created CB-5507
  
   I'll push it out this afternoon if there are no objections.
  
  
   On Fri, Nov 29, 2013 at 9:30 AM, Michal Mocny mmo...@chromium.org
  wrote:
  
   It landed, sorry I forgot to close the issue.
(cordova-android 42f4d49fc30ca37fb22309b92f104c2336f70c3f)
  
  
   On Fri, Nov 29, 2013 at 8:46 AM, Bryan Higgins 
 br...@bryanhiggins.net
   wrote:
  
Michal - how goes CB-5338? I'd love to get a point release out
 before
   the
weekend.
   
   
On Thu, Nov 28, 2013 at 3:16 PM, Bryan Higgins 
  br...@bryanhiggins.net
wrote:
   
 I've put a fix in for BB, which unfortunately has to contain
 custom
   code
 paths [1].

 The lazy load was putting files under blackberry10 sub-folder,
 when
   they
 have always lived directly in
~/.cordova/lib/blackberry10/cordova/VERSION

 I'm not sure why the windows platforms prefer to have the extra
 sub-directory, but we can't change the location for bb10 without
  also
 updating the platform version in platforms.js. There are active
  users
   who
 have already downloaded the 3.2 lib. Hopefully not many have
 started
 cleanly on 3.2.0-0.2.0, which would put them in a bad state.

 [1]

   
  
 
 https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=commit;h=f7a35b3ca8a8b787fbbe01aebed286802451b64a


 On Thu, Nov 28, 2013 at 10:52 AM, Andrew Grieve 
  agri...@chromium.org
wrote:

 On Thu, Nov 28, 2013 at 10:05 AM, Michal Mocny 
  mmo...@chromium.org
 wrote:

  If we are going to land another CLI point release, I suggest we
   wait
for
  CB-5338 as well to properly fix the android API version bump to
  18
   as
we
  planned for 3.2.  That should land soon/today.
 
  -Michal
 
 
  On Thu, Nov 28, 2013 at 10:00 AM, Bryan Higgins 
br...@bryanhiggins.net
  wrote:
 
   This update breaks BB10 badly.
  
   There was a change made to attempt standardizing platforms in
  sub-folders.
   I asked yesterday if this had been tested on BB10  The answer
  was
no.
  When
   I found some time to test it out (just now), it had already
  been
 merged
   into master and released to NPM.
  
   Perhaps if the commit messages had JIRA ids and something
 more
  descriptive
   than merging master from x, we'd have a clue about what
 we're
   releasing...
  
  
   On Wed, Nov 27, 2013 at 4:26 PM, Lorin Beer 
lorin.beer@gmail.com
   wrote:
  
Michael and I released another version of the Cordova CLI
  this
 morning.
   
This is a minor version bump, and includes a commit to fix
 a
 blocking
   issue
for projects that consume the Cordova CLI as a library.
 

 What is the issue? Is there a JIRA for it?

 Sounds like it's unlikely worse than having BB completely broken.
  I'd
like
 someone else to make the call since I'm still catching up on
  things,
   but
 sounds like we may want to roll back this point release until BB
 is
fixed.
 E.g., make it not latest tag in npm.


   
This was tested on OSX and Windows before the release, and
   should
 not
affect the Cordova CLI at all.
   
In the future, the list will be notified prior before even
 a
   minor
   release
like this.
 

 This was already the documented procedure. Bad call it seems :(.



   
- Lorin
   
  
 



   
  
  
  
 

Re: Cordova CLI minor update

[Bryan Higgins]

bhiggins, which I just added


On Fri, Nov 29, 2013 at 1:28 PM, Michal Mocny mmo...@chromium.org wrote:

 have you done npm adduser ?  I cannot find your account name


 On Fri, Nov 29, 2013 at 1:27 PM, Bryan Higgins br...@bryanhiggins.net
 wrote:

  Yes, please
 
 
  On Fri, Nov 29, 2013 at 1:26 PM, Michal Mocny mmo...@chromium.org
 wrote:
 
   Using br...@bryanhiggins.net ?
  
  
   On Fri, Nov 29, 2013 at 1:21 PM, Bryan Higgins br...@bryanhiggins.net
   wrote:
  
Could someone please add me as an owner so I can push out the update?
   
   
On Fri, Nov 29, 2013 at 9:46 AM, Bryan Higgins 
 br...@bryanhiggins.net
wrote:
   
 Created CB-5507

 I'll push it out this afternoon if there are no objections.


 On Fri, Nov 29, 2013 at 9:30 AM, Michal Mocny mmo...@chromium.org
 
wrote:

 It landed, sorry I forgot to close the issue.
  (cordova-android 42f4d49fc30ca37fb22309b92f104c2336f70c3f)


 On Fri, Nov 29, 2013 at 8:46 AM, Bryan Higgins 
   br...@bryanhiggins.net
 wrote:

  Michal - how goes CB-5338? I'd love to get a point release out
   before
 the
  weekend.
 
 
  On Thu, Nov 28, 2013 at 3:16 PM, Bryan Higgins 
br...@bryanhiggins.net
  wrote:
 
   I've put a fix in for BB, which unfortunately has to contain
   custom
 code
   paths [1].
  
   The lazy load was putting files under blackberry10 sub-folder,
   when
 they
   have always lived directly in
  ~/.cordova/lib/blackberry10/cordova/VERSION
  
   I'm not sure why the windows platforms prefer to have the
 extra
   sub-directory, but we can't change the location for bb10
 without
also
   updating the platform version in platforms.js. There are
 active
users
 who
   have already downloaded the 3.2 lib. Hopefully not many have
   started
   cleanly on 3.2.0-0.2.0, which would put them in a bad state.
  
   [1]
  
 

   
  
 
 https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=commit;h=f7a35b3ca8a8b787fbbe01aebed286802451b64a
  
  
   On Thu, Nov 28, 2013 at 10:52 AM, Andrew Grieve 
agri...@chromium.org
  wrote:
  
   On Thu, Nov 28, 2013 at 10:05 AM, Michal Mocny 
mmo...@chromium.org
   wrote:
  
If we are going to land another CLI point release, I
 suggest
  we
 wait
  for
CB-5338 as well to properly fix the android API version
 bump
  to
18
 as
  we
planned for 3.2.  That should land soon/today.
   
-Michal
   
   
On Thu, Nov 28, 2013 at 10:00 AM, Bryan Higgins 
  br...@bryanhiggins.net
wrote:
   
 This update breaks BB10 badly.

 There was a change made to attempt standardizing
 platforms
  in
sub-folders.
 I asked yesterday if this had been tested on BB10  The
  answer
was
  no.
When
 I found some time to test it out (just now), it had
 already
been
   merged
 into master and released to NPM.

 Perhaps if the commit messages had JIRA ids and something
   more
descriptive
 than merging master from x, we'd have a clue about what
   we're
 releasing...


 On Wed, Nov 27, 2013 at 4:26 PM, Lorin Beer 
  lorin.beer@gmail.com
 wrote:

  Michael and I released another version of the Cordova
 CLI
this
   morning.
 
  This is a minor version bump, and includes a commit to
  fix
   a
   blocking
 issue
  for projects that consume the Cordova CLI as a library.
   
  
   What is the issue? Is there a JIRA for it?
  
   Sounds like it's unlikely worse than having BB completely
  broken.
I'd
  like
   someone else to make the call since I'm still catching up on
things,
 but
   sounds like we may want to roll back this point release until
  BB
   is
  fixed.
   E.g., make it not latest tag in npm.
  
  
 
  This was tested on OSX and Windows before the release,
  and
 should
   not
  affect the Cordova CLI at all.
 
  In the future, the list will be notified prior before
  even
   a
 minor
 release
  like this.
   
  
   This was already the documented procedure. Bad call it seems
  :(.
  
  
  
 
  - Lorin
 

   
  
  
  
 



   
  
 

Re: Cordova CLI minor update

[Bryan Higgins]

Yep, it's tagged and I'm about to publish


On Fri, Nov 29, 2013 at 1:43 PM, Steven Gill stevengil...@gmail.com wrote:

 Yay! So 3.2.0-0.3.0?

 On Friday, November 29, 2013, Michal Mocny wrote:

  Done!
 
 
  On Fri, Nov 29, 2013 at 1:31 PM, Bryan Higgins br...@bryanhiggins.net
 javascript:;
  wrote:
 
   bhiggins, which I just added
  
  
   On Fri, Nov 29, 2013 at 1:28 PM, Michal Mocny mmo...@chromium.org
  wrote:
  
have you done npm adduser ?  I cannot find your account name
   
   
On Fri, Nov 29, 2013 at 1:27 PM, Bryan Higgins 
 br...@bryanhiggins.net
wrote:
   
 Yes, please


 On Fri, Nov 29, 2013 at 1:26 PM, Michal Mocny mmo...@chromium.org
 
wrote:

  Using br...@bryanhiggins.net ?
 
 
  On Fri, Nov 29, 2013 at 1:21 PM, Bryan Higgins 
   br...@bryanhiggins.net
  wrote:
 
   Could someone please add me as an owner so I can push out the
   update?
  
  
   On Fri, Nov 29, 2013 at 9:46 AM, Bryan Higgins 
br...@bryanhiggins.net
   wrote:
  
Created CB-5507
   
I'll push it out this afternoon if there are no objections.
   
   
On Fri, Nov 29, 2013 at 9:30 AM, Michal Mocny 
   mmo...@chromium.org

   wrote:
   
It landed, sorry I forgot to close the issue.
 (cordova-android 42f4d49fc30ca37fb22309b92f104c2336f70c3f)
   
   
On Fri, Nov 29, 2013 at 8:46 AM, Bryan Higgins 
  br...@bryanhiggins.net
wrote:
   
 Michal - how goes CB-5338? I'd love to get a point release
  out
  before
the
 weekend.


 On Thu, Nov 28, 2013 at 3:16 PM, Bryan Higgins 
   br...@bryanhiggins.net
 wrote:

  I've put a fix in for BB, which unfortunately has to
  contain
  custom
code
  paths [1].
 
  The lazy load was putting files under blackberry10
   sub-folder,
  when
they
  have always lived directly in
 ~/.cordova/lib/blackberry10/cordova/VERSION
 
  I'm not sure why the windows platforms prefer to have
 the
extra
  sub-directory, but we can't change the location for bb10
without
   also
  updating the platform version in platforms.js. There are
active
   users
who
  have already downloaded the 3.2 lib. Hopefully not many
  have
  started
  cleanly on 3.2.0-0.2.0, which would put them in a bad
  state.
 
  

Re: Cordova CLI minor update

[Bryan Higgins]

This update breaks BB10 badly.

There was a change made to attempt standardizing platforms in sub-folders.
I asked yesterday if this had been tested on BB10  The answer was no. When
I found some time to test it out (just now), it had already been merged
into master and released to NPM.

Perhaps if the commit messages had JIRA ids and something more descriptive
than merging master from x, we'd have a clue about what we're releasing...


On Wed, Nov 27, 2013 at 4:26 PM, Lorin Beer lorin.beer@gmail.comwrote:

 Michael and I released another version of the Cordova CLI this morning.

 This is a minor version bump, and includes a commit to fix a blocking issue
 for projects that consume the Cordova CLI as a library.

 This was tested on OSX and Windows before the release, and should not
 affect the Cordova CLI at all.

 In the future, the list will be notified prior before even a minor release
 like this.


 - Lorin

Re: Cordova CLI minor update

[Bryan Higgins]

I've put a fix in for BB, which unfortunately has to contain custom code
paths [1].

The lazy load was putting files under blackberry10 sub-folder, when they
have always lived directly in ~/.cordova/lib/blackberry10/cordova/VERSION

I'm not sure why the windows platforms prefer to have the extra
sub-directory, but we can't change the location for bb10 without also
updating the platform version in platforms.js. There are active users who
have already downloaded the 3.2 lib. Hopefully not many have started
cleanly on 3.2.0-0.2.0, which would put them in a bad state.

[1]
https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=commit;h=f7a35b3ca8a8b787fbbe01aebed286802451b64a


On Thu, Nov 28, 2013 at 10:52 AM, Andrew Grieve agri...@chromium.orgwrote:

 On Thu, Nov 28, 2013 at 10:05 AM, Michal Mocny mmo...@chromium.org
 wrote:

  If we are going to land another CLI point release, I suggest we wait for
  CB-5338 as well to properly fix the android API version bump to 18 as we
  planned for 3.2.  That should land soon/today.
 
  -Michal
 
 
  On Thu, Nov 28, 2013 at 10:00 AM, Bryan Higgins br...@bryanhiggins.net
  wrote:
 
   This update breaks BB10 badly.
  
   There was a change made to attempt standardizing platforms in
  sub-folders.
   I asked yesterday if this had been tested on BB10  The answer was no.
  When
   I found some time to test it out (just now), it had already been merged
   into master and released to NPM.
  
   Perhaps if the commit messages had JIRA ids and something more
  descriptive
   than merging master from x, we'd have a clue about what we're
   releasing...
  
  
   On Wed, Nov 27, 2013 at 4:26 PM, Lorin Beer lorin.beer@gmail.com
   wrote:
  
Michael and I released another version of the Cordova CLI this
 morning.
   
This is a minor version bump, and includes a commit to fix a blocking
   issue
for projects that consume the Cordova CLI as a library.
 

 What is the issue? Is there a JIRA for it?

 Sounds like it's unlikely worse than having BB completely broken. I'd like
 someone else to make the call since I'm still catching up on things, but
 sounds like we may want to roll back this point release until BB is fixed.
 E.g., make it not latest tag in npm.


   
This was tested on OSX and Windows before the release, and should not
affect the Cordova CLI at all.
   
In the future, the list will be notified prior before even a minor
   release
like this.
 

 This was already the documented procedure. Bad call it seems :(.



   
- Lorin
   
  
 

Re: Cordova Debug Mode

[Bryan Higgins]

FWIW, BB10 does respect --debug (default) and --release flags passed into
build.

In debug mode, remote web inspector is enabled and the app is not signed.


On Mon, Nov 25, 2013 at 1:48 PM, Michal Mocny mmo...@chromium.org wrote:

 You have to explicitly enable remote debugging for kitkat chrome-based
 webview:

 https://developers.google.com/chrome-developer-tools/docs/remote-debugging#debugging-webviews

 Existing cordova platforms do not do this.  I think it would be a good
 preference to add for the android platform for 3.3, but you can add it
 yourself following the above instructions.

 As far as I am aware there are no performance implication to leaving this
 flag on at all time (i.e. when releasing your app) -- but the flag
 implemented as an opt-in so that users cannot inspect your webview based
 application without your consent.  I think cordova should respect that and
 leave the option off by default as well.

 -Michal


 On Mon, Nov 25, 2013 at 9:11 AM, Dick Van den Brink 
 d_vandenbr...@outlook.com wrote:

  @Jan
  Remote debugging is possible with for example
 https://www.jshybugger.com/
 
  On Android 4.4 It is possible to debug without a plugin.
 
  Sent from my Windows Phone
  
  From: Jan Becickamailto:jan.beci...@oracle.com
  Sent: 11/25/2013 17:05
  To: dev@cordova.apache.orgmailto:dev@cordova.apache.org
  Subject: Re: Cordova Debug Mode
 
   * Enabling the remote debugger in Android 4.4+
 
  Btw does cordova support remote debugging on Android? Is there a way how
  to enable it for cordova apps? I tried to google it, but I failed.
  Thanks,
  Jan
 
 
 

Re: 3.2.0 blog review

[Bryan Higgins]

Carlos - I just verified this as well. It was working well in the RC1
version.

Re-tag?


On Fri, Nov 22, 2013 at 10:15 AM, Carlos Santana csantan...@gmail.comwrote:

 How do we pick up this blocker [1] for blackberry in CLI 3.2.0-0.1.0 ?


 [1]: https://issues.apache.org/jira/browse/CB-5467



 On Fri, Nov 22, 2013 at 9:55 AM, Marcel Kinard cmarc...@gmail.com wrote:

  One clarification: the platform upgrade guide for iOS does have content
  for 3.2.0 in git, but isn't published to cordova.apache.org/docs. The
  other platform upgrade guides don't have content for 3.2.0 in git.
 
  On Nov 22, 2013, at 9:39 AM, Marcel Kinard cmarc...@gmail.com wrote:
 
  
 http://cordova.apache.org/docs/en/3.2.0/guide_platforms_index.md.htmlreturnsa 
 404, which I guess is expected since the docs haven't been cut
  yet.
  
   But more importantly, none of the platform upgrade guides have content
  for 3.2.0 (I'm looking in edge).
 
 


 --
 Carlos Santana
 csantan...@gmail.com

Re: cordova serve broken

[Bryan Higgins]

To be fair to Josh, the semantic change was made long before he started
working on this project. He simply noticed serve was broken and sent a
patch to the list for review.


On Wed, Nov 13, 2013 at 11:19 AM, Brian LeRoux b...@brian.io wrote:

 Thx Dick.

 So, Braden/Josh: did we discuss these semantics changes on list at all or
 was this just colloquially decided out off list and implemented? The latter
 is not cool. If I missed the former I apologize.

 I don't have a problem with this new feature per se but I don't think it
 has been thoroughly discussed (regardless), and obviously it has not been
 well tested (if at all).

 And I do have trouble with adding stuff to an already very large project.
 Do we need the new url scheme for app harness? If so, a landing page thing
 makes sense, I guess. Feels like we walking into territory that belongs to
 tooling like Grunt however. Could we have worked together to use the
 designer resources available from other committers to make it look better
 than an error state? Yes.

 Mild rant time.

 We have to use this list to keep everyone in the loop on the work being
 done. We can help each other create solid releases with beautiful
 experiences. Quietly introducing new semantics, untested, and a frankly
 terrible looking experience is a step backwards and worst of all it wasn't
 necessary. I am certain this was not deliberate or malicious but I do think
 it sucks.

 I am asking everyone here to think before you rock a large changeset, make
 smaller atomic changes that are thoroughly discussed, and give everyone
 here the opportunity to contribute to the effort. Each release should be an
 improvement on the last.








 On Wed, Nov 13, 2013 at 12:21 AM, Dick Van den Brink 
 d_vandenbr...@outlook.com wrote:

  Issue created: https://issues.apache.org/jira/browse/CB-5368
  I tested on master and 3.2.0rc, not working in IE11, working in other
  browsers.
  Landing page is working in all browsers.
 
 
   From: jso...@blackberry.com
   To: dev@cordova.apache.org; d_vandenbr...@outlook.com; b...@brian.io;
  timki...@gmail.com
   CC: j...@blackberry.com
   Subject: Re: cordova serve broken
   Date: Wed, 13 Nov 2013 05:39:42 +
  
   Andrew wrote:
   Sounds issue-worthy.
  
   I think Josh added some usage messages to serve
  
   Yes, I drove changes by our team here.
  
   (and a landing page for /),
  
   Yep, especially this
  
   so the next release will be more user-friendly.
  
   Speaking of which, there's a release candidate available now, please
 try
  the following:
  
   npm install -g cordova@3.2.0-rc.1
  
  
   cordova create directory com.example.hello HelloWorld
   cd directory
   cordova platform add blackberry10
  
   cordova serve
  
   And then visit http://localhost:8000 in your browsers.
  
   We're doing testing of Cordova 3.2 RC this week and I'm happy to work
 on
  things that are identified.
  
   I have OS X 10.9 and Windows 8 handy along with some VMs from
 modern.ie.
  If there are browsers that should be tested, please let us know.
  
   The landing page isn't particularly shiny as I don't usually spend time
  on CSS. Patches or suggestions are welcome.
   -
   This transmission (including any attachments) may contain confidential
  information, privileged material (including material protected by the
  solicitor-client or other applicable privileges), or constitute
 non-public
  information. Any use of this information by anyone other than the
 intended
  recipient is prohibited. If you have received this transmission in error,
  please immediately reply to the sender and delete this information from
  your system. Use, dissemination, distribution, or reproduction of this
  transmission by unintended recipients is not authorized and may be
  unlawful.
 

Review Request 15461: config_parser - handle duplicates with children and text when merging

[Bryan Higgins]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/15461/
---

Review request for cordova and Jeffrey Heifetz.


Repository: cordova-cli


Description
---

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


Diffs
-

  src/config_parser.js 11667d3 

Diff: https://reviews.apache.org/r/15461/diff/


Testing
---


Thanks,

Bryan Higgins

Re: MSDN subscriptions for contributors

[Bryan Higgins]

thanks Jesse!


On Fri, Nov 8, 2013 at 9:25 AM, James Jong wjamesj...@gmail.com wrote:

 nice… thanks Jesse!
 -James Jong

 On Nov 7, 2013, at 9:04 PM, Jesse purplecabb...@gmail.com wrote:

  I can't find the original email in my archives, but here is an email
  mentioning the availability of MSDN to apache commiters.[1]
 
  You'll need to go to [2] with your svn credentials and fill out the form.
  And I think you need to do it every year.
 
 
  [1]
 
 http://apache-database.10148.n7.nabble.com/Microsoft-MSDN-licenses-for-Apache-committers-td117850.html
  [2]
 
 https://svn.apache.org/repos/private/committers/donated-licenses/msdn-subscription.html
 
 
 
 
  @purplecabbage
  risingj.com

Re: Tools release today?

[Bryan Higgins]

Josh - most of those are not plugman changes and are not critical.

I see only the process.exit change for plugman. It's better to give that
more time to bake than to rush it out.


On Fri, Nov 8, 2013 at 12:22 PM, Josh Soref jso...@blackberry.com wrote:

 I'd like to have a few things included:

 CB 5320, CB 5311, CB 5258 (with a bit more massaging) , CB 5248, CB 5223,
 CB 5031, CB 5082 (@ Jenny: test? ), CB 5034 (I need to test or fix this
 request) ,

 I need to figure out what's in CB 4570 (@ Bryan? )

 I have a few other notes, but I've been interrupted
 -
 This transmission (including any attachments) may contain confidential
 information, privileged material (including material protected by the
 solicitor-client or other applicable privileges), or constitute non-public
 information. Any use of this information by anyone other than the intended
 recipient is prohibited. If you have received this transmission in error,
 please immediately reply to the sender and delete this information from
 your system. Use, dissemination, distribution, or reproduction of this
 transmission by unintended recipients is not authorized and may be unlawful.