cs.google.com/document/d/1uJ5qXqQxK2oh1eZPgMdYuhK2rQTB7QMHXUHbkcomWgk/edit?usp=sharing
> >
> >
> >
> > From: Ray Camden
> > Sent: Wednesday, April 30, 2014 11:28 AM
> > To: dev@cordova.apache.org
> > Subject: RE: Some p
invited folks only.
>
>
> https://docs.google.com/document/d/1uJ5qXqQxK2oh1eZPgMdYuhK2rQTB7QMHXUHbkcomWgk/edit?usp=sharing
>
>
>
> From: Ray Camden
> Sent: Wednesday, April 30, 2014 11:28 AM
> To: dev@cordova.apache.org
> Subject:
sp=sharing
From: Ray Camden
Sent: Wednesday, April 30, 2014 11:28 AM
To: dev@cordova.apache.org
Subject: RE: Some pain points from our users :'(
On it.
From: Steven Gill
Sent: Wednesday, April 30, 2014 11:12 AM
To: dev@cordova.apa
On it.
From: Steven Gill
Sent: Wednesday, April 30, 2014 11:12 AM
To: dev@cordova.apache.org
Subject: RE: Some pain points from our users :'(
I would suggest creating a Google doc and sharing it here.
On Apr 30, 2014 8:59 AM, "Ray Camden"
esday, April 30, 2014 10:41 AM
> To: dev@cordova.apache.org
> Subject: Re: Some pain points from our users :'(
>
> How about here? https://wiki.apache.org/cordova/signposts-draft . I'd
> hope this works, as long as the contributions are considered "trivial" by
Crap, I spoke too soon. it is a "Immutable Page" and I can't edit it.
From: Marcel Kinard
Sent: Wednesday, April 30, 2014 10:41 AM
To: dev@cordova.apache.org
Subject: Re: Some pain points from our users :'(
How about here? https://wik
day, April 30, 2014 10:41 AM
To: dev@cordova.apache.org
Subject: Re: Some pain points from our users :'(
How about here? https://wiki.apache.org/cordova/signposts-draft . I'd hope this
works, as long as the contributions are considered "trivial" by Apache
standards. Othe
How about here? https://wiki.apache.org/cordova/signposts-draft . I'd hope this
works, as long as the contributions are considered "trivial" by Apache
standards. Otherwise pull requests to cordova-doc.git would be the [slower and
more proper] way to go.
On Apr 30, 2014, at 11:29 AM, Ray Camden
: Some pain points from our users :'(
How about using a short-term wiki page to create/grow the draft? Then it could
migrate into cordova-docs.git.
Getting to the end of the Cordova docs with a working helloWorld, and then
having signposts for the next places to go would be a significant ga
How about using a short-term wiki page to create/grow the draft? Then it could
migrate into cordova-docs.git.
Getting to the end of the Cordova docs with a working helloWorld, and then
having signposts for the next places to go would be a significant gain in the
perceived usability of Cordova.
when happy?
From: Joe Bowser
Sent: Tuesday, April 29, 2014 3:12 PM
To: dev
Subject: Re: Some pain points from our users :'(
+1 to this post, who wants to take this on?
On Tue, Apr 29, 2014 at 12:22 PM, Joerg Holz wrote:
> I’m developing B2B-App
On Tue, Apr 29, 2014 at 4:12 PM, Joe Bowser wrote:
> +1 to this post, who wants to take this on?
>
> On Tue, Apr 29, 2014 at 12:22 PM, Joerg Holz wrote:
> > I’m developing B2B-Apps (iOS and Android), using cordova.
> >
> > First of all, thank you for your great job. From release to release
> thi
+1 for Joerg's comments. There has been a long outstanding bug to create a
"Next Steps" guide: https://issues.apache.org/jira/browse/CB-677
I know I personally do not "eat my own dogfood" enough, and I'm sure the
same can be said about a lot of us on this list. It can be pretty difficult
to even r
+1 to this post, who wants to take this on?
On Tue, Apr 29, 2014 at 12:22 PM, Joerg Holz wrote:
> I’m developing B2B-Apps (iOS and Android), using cordova.
>
> First of all, thank you for your great job. From release to release things
> are going easier and tidier.
>
> It is relatively easy for
I’m developing B2B-Apps (iOS and Android), using cordova.
First of all, thank you for your great job. From release to release things are
going easier and tidier.
It is relatively easy for a beginner to start with cordova, but in a bigger
project there are a lot of small jobs and decisions, whic
Sorry, I'm a little late to the party here...
On Mon, Apr 28, 2014 at 4:35 PM, Marcel Kinard wrote:
> How about this:
>
> 1) No API changes within a minor version bump.
We try (maybe we could do better at this) to follow the guidelines at
http://www.semver.org for all of the cordova subprojec
Jim Jagielski wrote:
> But code that is "constantly" changing also means people
> cannot standardize on it and they look for something more
> "stable"... The trick is to find that happy medium.
This is nonsense. [Yes, I'm feeding a troll. This may be the last time, I
might have to investigate kill
On Tue, Apr 29, 2014 at 4:55 AM, Jim Jagielski wrote:
>
> On Apr 28, 2014, at 2:44 PM, Brian LeRoux wrote:
>
>> I feel the comments there are not really constructive or fair. Cordova
>> changes too much? Sorry, static code means bitrot aka abandonware.
>
> True. But code that is "constantly" chan
On Apr 28, 2014, at 2:44 PM, Brian LeRoux wrote:
> I feel the comments there are not really constructive or fair. Cordova
> changes too much? Sorry, static code means bitrot aka abandonware.
True. But code that is "constantly" changing also means people
cannot standardize on it and they look fo
Oh yeah, this too:
https://github.com/infil00p/cordova-android/commit/9911202d5b2a5f07ba2050176f72c3642a34a8c6
On Mon, Apr 28, 2014 at 2:49 PM, Joe Bowser wrote:
> On Mon, Apr 28, 2014 at 2:32 PM, Freak Show wrote:
>>
>>
>> I guess maybe you're new.
>
> https://github.com/phonegap/phonegap/comm
For what it's worth, the biggest problem I've had in upgrading is with
'phonegap plugin add '. The native code gets copied but
cordova_plugins.js doesn't get updated and the plugin JS isn't wrapped
in a call to cordova.define. In a couple of Stack Overflow posts,
running 'phonegap build ' aft
On Mon, Apr 28, 2014 at 2:32 PM, Freak Show wrote:
>
>
> I guess maybe you're new.
https://github.com/phonegap/phonegap/commit/1beb1b5f6ac7470eb516768ef52ceda8df6278e1
On Apr 28, 2014, at 1:54 PM, Joe Bowser wrote:
> On Mon, Apr 28, 2014 at 1:49 PM, Freak Show wrote:
>>
>> On Apr 28, 2014, at 1:36 PM, Joe Bowser wrote:
>>
>>> This wasn't necessary and I was against it.
>>
>> Cool - now there are two of us.
>
> Strange, I don't remember hearing from you b
Marcel Kinard wrote:
>How about this:
>1) No API changes within a minor version bump. For example, we're looking
>at some "consistency improvements" to the globalization plugin that would
>change the return values. That should trigger a major version bump, even
>if the signatures/parms don't change
Cordova has a CLI. The fact that PhoneGap has one and is different is
irrelevant to this list. This is the Cordova mailing list. Why is it
different? We donated the PhoneGap source to Apache and it needs to be
different for a variety of reasons I'd be happy to share on a personal
thread or over a b
Listening to our developer community is important but it should come with
the balance that we do make decisions for a good reason, and as Joe
mentoined, this is open source so anyone is free to contribute. The
spectrum of contribution includes complaint though we tend to prefer those
in the form of
On Mon, Apr 28, 2014 at 1:49 PM, Freak Show wrote:
>
> On Apr 28, 2014, at 1:36 PM, Joe Bowser wrote:
>
>> This wasn't necessary and I was against it.
>
> Cool - now there are two of us.
Strange, I don't remember hearing from you before today? Which commits
are you responsible for?
On Apr 28, 2014, at 1:36 PM, Joe Bowser wrote:
> This wasn't necessary and I was against it.
Cool - now there are two of us.
> These reasons were legal, and it was done to keep PhoneGap open
> source. If we didn't do this, we wouldn't be having this
> conversation.
And this explains where t
On Mon, Apr 28, 2014 at 1:01 PM, Freak Show wrote:
>
> Because 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, etcall came with some fatal problem
> relative to 1.2. Some plugin or other was broken. None of those versions
> offered new capabilities - but often came with new bugs. That's my
> perspective o
How about this:
1) No API changes within a minor version bump. For example, we're looking at
some "consistency improvements" to the globalization plugin that would change
the return values. That should trigger a major version bump, even if the
signatures/parms don't change. As a consumer of Cor
I think they are fair, or at least were.
I have an app running on 1.2. Its staying there. Why?
Because 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, etcall came with some fatal problem
relative to 1.2. Some plugin or other was broken. None of those versions
offered new capabilities - but often came with
s/mailing list/distribution list/
On Mon, Apr 28, 2014 at 3:14 PM, Michal Mocny wrote:
> I think this particular users' frustration is not addressable (and his
> feedback in places is just annoying: "you work for X and I demand that you
> should have the money to do everything for me").
> He h
I think this particular users' frustration is not addressable (and his
feedback in places is just annoying: "you work for X and I demand that you
should have the money to do everything for me").
He hasn't maintained his project for 2 years, hasn't read our docs, hasn't
written tests to guard again
We need to clone Tommy for the various channels and convince Mike Sierra to
come back and continue docs. Good problems to have at least.
On Mon, Apr 28, 2014 at 11:54 AM, Shazron wrote:
> We come with a (framework) developer's perspective, thus an echo chamber.
> The comments may or may not be
We come with a (framework) developer's perspective, thus an echo chamber.
The comments may or may not be fair but the users do encounter pain, and I
think it does help in identifying issues we missed (reading from the list
overall). Canary in the coal mine, etc.
Filing issues etc ideal, but some,
On Mon, Apr 28, 2014 at 11:44 AM, Brian LeRoux wrote:
> I feel the comments there are not really constructive or fair. Cordova
> changes too much? Sorry, static code means bitrot aka abandonware.
>
> We work on Cordova because we are improving it for the many thousands of
> our users whom apprecia
Shazron wrote:
>See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ
While I haven't written it, I've contemplated the metadata required for an
update check that could tell you when a given api breaks.
> because the API for device.platform changed and returned "ios" instead
>of
Can we keep track of which users make up which conspiracy theory, and
the company that gets mentioned as ruining Cordova the most has to buy
beer? I say this because at least this time Google got mentioned with
Adobe, as opposed to "Adobe is going to kill
PhoneGap1!!!eleventyone!!!" (Seriously,
I feel the comments there are not really constructive or fair. Cordova
changes too much? Sorry, static code means bitrot aka abandonware.
We work on Cordova because we are improving it for the many thousands of
our users whom appreciate that. I don't need to tell you guys that but 1.8
was a mess c
See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ
40 matches
Mail list logo
