Re: Some pain points from our users :'(
Sorry for being late to the party. When I was a consumer of Phonegap back in the days, my most precious doc was the upgrade guides [1]. We didn't have the bandwidth or test process to update our app with every release of phonegap. But when it was time to upgrade (i.e. 1.4 to 1.9) The upgrade guide was my only resource to go over every change release by release, and I was happy after a week getting my app updated. I think having the same for the Plugins will be of benefit to the consumers. In order of priorities: *1. Having a upgrade guide per plugin including api changes* 2. If we can, try to adopt semver and change the version according to the level of change As we document the breaking changes, we will feel the pain of consumers, and as we write a lot of doc for upgrading we will want not to doc and leave the api stable. [1]: http://cordova.apache.org/docs/en/3.4.0/guide_platforms_android_upgrading.md.html#Upgrading%20Android http://cordova.apache.org/docs/en/3.4.0/guide_platforms_ios_upgrading.md.html#Upgrading%20iOS On Wed, Apr 30, 2014 at 9:36 AM, Michal Mocny wrote: > Thanks for choosing a saner option than the wiki ;) > > > On Wed, Apr 30, 2014 at 12:34 PM, Ray Camden wrote: > > > Ok folks, here is the document. I even took a quick stab at an outline. > > I've set this as Anyone Can Edit, but if that causes problems I'll set it > > back to 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: RE: Some pain points from our users :'( > > > > 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" wrote: > > > > > 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://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 wrote: > > > > > > > Any particular place? Sorry if obvious - but it would need to be a > > > github repo multiple folks can edit. (Seems like that would be quicker > > than > > > PRs imo.) > > > > > > -- Carlos Santana
Re: Some pain points from our users :'(
Thanks for choosing a saner option than the wiki ;) On Wed, Apr 30, 2014 at 12:34 PM, Ray Camden wrote: > Ok folks, here is the document. I even took a quick stab at an outline. > I've set this as Anyone Can Edit, but if that causes problems I'll set it > back to 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: RE: Some pain points from our users :'( > > 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" wrote: > > > 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://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 wrote: > > > > > Any particular place? Sorry if obvious - but it would need to be a > > github repo multiple folks can edit. (Seems like that would be quicker > than > > PRs imo.) > > >
RE: Some pain points from our users :'(
Ok folks, here is the document. I even took a quick stab at an outline. I've set this as Anyone Can Edit, but if that causes problems I'll set it back to 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: RE: Some pain points from our users :'( 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" wrote: > 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://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 wrote: > > > Any particular place? Sorry if obvious - but it would need to be a > github repo multiple folks can edit. (Seems like that would be quicker than > PRs imo.) >
RE: Some pain points from our users :'(
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" wrote: > 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://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 wrote: > > > Any particular place? Sorry if obvious - but it would need to be a > github repo multiple folks can edit. (Seems like that would be quicker than > PRs imo.) >
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" wrote: > 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://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 wrote: > > > Any particular place? Sorry if obvious - but it would need to be a > github repo multiple folks can edit. (Seems like that would be quicker than > PRs imo.) >
RE: Some pain points from our users :'(
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://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 wrote: > Any particular place? Sorry if obvious - but it would need to be a github > repo multiple folks can edit. (Seems like that would be quicker than PRs imo.)
RE: Some pain points from our users :'(
It took some time to actually register, but I'll give it a shot. Traveling today but will try to get a basic outline up there asap. (And anyone else listening - don't wait for me - attack the doc if you can. :) 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://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 wrote: > Any particular place? Sorry if obvious - but it would need to be a github > repo multiple folks can edit. (Seems like that would be quicker than PRs imo.)
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. 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 wrote: > Any particular place? Sorry if obvious - but it would need to be a github > repo multiple folks can edit. (Seems like that would be quicker than PRs imo.)
RE: Some pain points from our users :'(
Any particular place? Sorry if obvious - but it would need to be a github repo multiple folks can edit. (Seems like that would be quicker than PRs imo.) From: Marcel Kinard Sent: Wednesday, April 30, 2014 10:22 AM To: dev@cordova.apache.org Subject: Re: 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 gain in the perceived usability of Cordova. Ray, thank you! On Apr 30, 2014, at 9:11 AM, Ray Camden wrote: > I'd love to take a stab at this. Where would be a good place for to post a > draft that folks could edit and the Cordova team could just take it over when > happy?
Re: 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 gain in the perceived usability of Cordova. Ray, thank you! On Apr 30, 2014, at 9:11 AM, Ray Camden wrote: > I'd love to take a stab at this. Where would be a good place for to post a > draft that folks could edit and the Cordova team could just take it over when > happy?
RE: Some pain points from our users :'(
I've had some recent discussions on this myself - and it came up at the open PhoneGap/Cordova session I hosted online a few days back. I'd love to take a stab at this. Where would be a good place for to post a draft that folks could edit and the Cordova team could just take it over 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-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, which have to be made: > The developer has to write clean html, js and css. Has to take care of: > structure of the project, strategy to fall back and restart the project, > testing, ui and ux, perhaps knowledge about a js-framework, sqlite, the > plugin-things, … > > It needs a lot of time to get into all this stuff, learning the tricks and > finding a good way for developing. >
Re: Some pain points from our users :'(
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 > things are going easier and tidier. > Thank you. > > > > 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, which have to > be made: The developer has to write clean html, js and css. Has to take > care of: structure of the project, strategy to fall back and restart the > project, testing, ui and ux, perhaps knowledge about a js-framework, > sqlite, the plugin-things, … > > > > It needs a lot of time to get into all this stuff, learning the tricks > and finding a good way for developing. > > > > I know, it ist not your job to teach people how to do all this stuff, > but it would be very helpfully, if there were a page in the documentation > «The steps after the hello world example». Not a tutorial, just a few > sentences and some links to going deeper into hybrid development. > > > > You are the developers of cordova, but there is a need for a bridge to > the «customers» using cordova. (I’m still thinking about starting a blog, > writing down my experiences.) > > > > > > Some suggestions: > > > > – It would be helpful, if cordova could write a «create script», a > special kind of log-file, in the project folder. In this create-script all > steps for recreating the project are listed. > I think this is being addressed. I suspect we are 1-2 releases away from a CLI workflow where in-place upgrades / git sharing of projects / workspace recreation / in-place plugin creation, etc, are all very common sense and happen exactly the way you should expect. > > > > – From the beginner side, it would be much easier to symlink the > www-files in the root to the platform www-files. > We try. There are already some virtual links created inside the IDE's (eclipse, xcode) to root www/, but it isn't perfect. Plugin files aren't linked. If you actually look at the platforms/ dir, you won't find links because the build systems require physical files. The best way to address this problem is to continue to replace the need to modify platforms/ directly, and make that workflow obvious & enjoyable for developers. > > > > – There is a need to write in the documentation on which version of each > platform cordova and the plugins are tested and running. > This is somewhat addressed for platforms, but our plugin version matching has sucked. We've mostly gotten away with this because most of the API's haven't changed significantly, but where they have changed (e.g. File) the experience has been terrible. This is a bug, that isn't being worked on enough. > > > > > > In my opinion, the most important software thing is, to solve the plugin > situation, which are not in the core. I know, it ist not your job, but > there is a need for other plugins and it is horrible to test them. > Do you mean the quality or workflow? I think we should make plugin development / upgrades / publishing easier, but I'm not sure we can solve the quality problem. > > > > Cordova is great, but it is not simple as it seems to be. I see a need > to go more into the customer-view. > > > > > > > > Am 29.04.2014 um 20:02 schrieb Ian Clelland : > > > >> 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 subprojects, *except* for > the > >> main platform's version number, which we've kind of declared to be a > >> "marketing" version number. > >> > >> According to semver, the rule should be "No API changes with only a > patch > >> version bump. Only backwards-combatible API changes with a minor version > >> bump." In practice, this means that the patch version gets incremented > with > >> bug fixes, and any *new* APIs can be added with a minor version > increment. > >> Any backwards-incompatible changes *require* a major 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. > >> > >> > >> If the API signatures don't change, then we'd have to consider what *is* > >> changing? If it's just the output, and it's incorrect in version A and > >> correct in version B, then that sounds like a bug fix. If the output is > >> different in a meaningful way then maybe that's minor, maybe major. (I > >> would suggest that it's minor only if the output is definitely *better* > in > >> every case with the new ve
Re: Some pain points from our users :'(
+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 recognize that users are having the problems Joerg describes - we've simply gotten so used to the project that it's hard to "take a step back." This is why mining Stack Overflow and the Google group are huge. Maybe we should send out a survey to the GG asking what kind of "next steps / growing pains" should be listed. I don't think that we necessarily should be writing this documentation ourselves though, but instead linking to various blog articles. See Michael's comment in the JIRA item. Joerg can you please copy your comments into the above JIRA issue? 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 > 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, which have to > be made: The developer has to write clean html, js and css. Has to take > care of: structure of the project, strategy to fall back and restart the > project, testing, ui and ux, perhaps knowledge about a js-framework, > sqlite, the plugin-things, … > > > > It needs a lot of time to get into all this stuff, learning the tricks > and finding a good way for developing. > > > > I know, it ist not your job to teach people how to do all this stuff, > but it would be very helpfully, if there were a page in the documentation > «The steps after the hello world example». Not a tutorial, just a few > sentences and some links to going deeper into hybrid development. > > > > You are the developers of cordova, but there is a need for a bridge to > the «customers» using cordova. (I’m still thinking about starting a blog, > writing down my experiences.) > > > > > > Some suggestions: > > > > – It would be helpful, if cordova could write a «create script», a > special kind of log-file, in the project folder. In this create-script all > steps for recreating the project are listed. > > > > – From the beginner side, it would be much easier to symlink the > www-files in the root to the platform www-files. > > > > – There is a need to write in the documentation on which version of each > platform cordova and the plugins are tested and running. > > > > > > In my opinion, the most important software thing is, to solve the plugin > situation, which are not in the core. I know, it ist not your job, but > there is a need for other plugins and it is horrible to test them. > > > > Cordova is great, but it is not simple as it seems to be. I see a need > to go more into the customer-view. > > > > > > > > Am 29.04.2014 um 20:02 schrieb Ian Clelland : > > > >> 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 subprojects, *except* for > the > >> main platform's version number, which we've kind of declared to be a > >> "marketing" version number. > >> > >> According to semver, the rule should be "No API changes with only a > patch > >> version bump. Only backwards-combatible API changes with a minor version > >> bump." In practice, this means that the patch version gets incremented > with > >> bug fixes, and any *new* APIs can be added with a minor version > increment. > >> Any backwards-incompatible changes *require* a major 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. > >> > >> > >> If the API signatures don't change, then we'd have to consider what *is* > >> changing? If it's just the output, and it's incorrect in version A and > >> correct in version B, then that sounds like a bug fix. If the output is > >> different in a meaningful way then maybe that's minor, maybe major. (I > >> would suggest that it's minor only if the output is definitely *better* > in > >> every case with the new version, but can still be consumed in exactly > the > >> same way) > >> > >> > >>> As a consumer of Cordova, you should be able to have some confidence > that > >>> if there isn't a major version bump, you shouldn't need to change your > >>> calling code. > >>> > >>> > >> Absolutely. If any change to client code is required, there should be
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-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, which have to be made: > The developer has to write clean html, js and css. Has to take care of: > structure of the project, strategy to fall back and restart the project, > testing, ui and ux, perhaps knowledge about a js-framework, sqlite, the > plugin-things, … > > It needs a lot of time to get into all this stuff, learning the tricks and > finding a good way for developing. > > I know, it ist not your job to teach people how to do all this stuff, but it > would be very helpfully, if there were a page in the documentation «The steps > after the hello world example». Not a tutorial, just a few sentences and some > links to going deeper into hybrid development. > > You are the developers of cordova, but there is a need for a bridge to the > «customers» using cordova. (I’m still thinking about starting a blog, writing > down my experiences.) > > > Some suggestions: > > – It would be helpful, if cordova could write a «create script», a special > kind of log-file, in the project folder. In this create-script all steps for > recreating the project are listed. > > – From the beginner side, it would be much easier to symlink the www-files in > the root to the platform www-files. > > – There is a need to write in the documentation on which version of each > platform cordova and the plugins are tested and running. > > > In my opinion, the most important software thing is, to solve the plugin > situation, which are not in the core. I know, it ist not your job, but there > is a need for other plugins and it is horrible to test them. > > Cordova is great, but it is not simple as it seems to be. I see a need to go > more into the customer-view. > > > > Am 29.04.2014 um 20:02 schrieb Ian Clelland : > >> 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 subprojects, *except* for the >> main platform's version number, which we've kind of declared to be a >> "marketing" version number. >> >> According to semver, the rule should be "No API changes with only a patch >> version bump. Only backwards-combatible API changes with a minor version >> bump." In practice, this means that the patch version gets incremented with >> bug fixes, and any *new* APIs can be added with a minor version increment. >> Any backwards-incompatible changes *require* a major 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. >> >> >> If the API signatures don't change, then we'd have to consider what *is* >> changing? If it's just the output, and it's incorrect in version A and >> correct in version B, then that sounds like a bug fix. If the output is >> different in a meaningful way then maybe that's minor, maybe major. (I >> would suggest that it's minor only if the output is definitely *better* in >> every case with the new version, but can still be consumed in exactly the >> same way) >> >> >>> As a consumer of Cordova, you should be able to have some confidence that >>> if there isn't a major version bump, you shouldn't need to change your >>> calling code. >>> >>> >> Absolutely. If any change to client code is required, there should be a >> major version bump. (Within reason: any bug could be depended on by >> someone; see https://xkcd.com/1172/) >> >> >> >>> 2) When doing an upgrade of plugins or platform, if there is a major >>> version bump to any of those components, the CLI should make it really >>> clear (a warning) that there may be a breaking change(s) and give them the >>> opportunity to abort the upgrade. >>> >> >> +1. We really need this. Maybe, like Debian, an upgrade should only ever >> upgrade within the same major release, and a harder upgrade command would >> be required for upgrading the major. >> >> Of course, this is all wishful thinking right now, since there's no upgrade >> command at all. The "upgrade" path is currently "remove plugin; re-add >> plugin", and I don't think that that flow should ever keep old metadata >> around. >> >> >>> 3) Keep the Upgrading Guides in the docs complete. So if they want to look >>> at what needs to change, these docs should at least give them a feel for >>> the order of magnitude, or better yet exactly what would be required.
Re: Some pain points from our users :'(
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, which have to be made: The developer has to write clean html, js and css. Has to take care of: structure of the project, strategy to fall back and restart the project, testing, ui and ux, perhaps knowledge about a js-framework, sqlite, the plugin-things, … It needs a lot of time to get into all this stuff, learning the tricks and finding a good way for developing. I know, it ist not your job to teach people how to do all this stuff, but it would be very helpfully, if there were a page in the documentation «The steps after the hello world example». Not a tutorial, just a few sentences and some links to going deeper into hybrid development. You are the developers of cordova, but there is a need for a bridge to the «customers» using cordova. (I’m still thinking about starting a blog, writing down my experiences.) Some suggestions: – It would be helpful, if cordova could write a «create script», a special kind of log-file, in the project folder. In this create-script all steps for recreating the project are listed. – From the beginner side, it would be much easier to symlink the www-files in the root to the platform www-files. – There is a need to write in the documentation on which version of each platform cordova and the plugins are tested and running. In my opinion, the most important software thing is, to solve the plugin situation, which are not in the core. I know, it ist not your job, but there is a need for other plugins and it is horrible to test them. Cordova is great, but it is not simple as it seems to be. I see a need to go more into the customer-view. Am 29.04.2014 um 20:02 schrieb Ian Clelland : > 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 subprojects, *except* for the > main platform's version number, which we've kind of declared to be a > "marketing" version number. > > According to semver, the rule should be "No API changes with only a patch > version bump. Only backwards-combatible API changes with a minor version > bump." In practice, this means that the patch version gets incremented with > bug fixes, and any *new* APIs can be added with a minor version increment. > Any backwards-incompatible changes *require* a major 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. > > > If the API signatures don't change, then we'd have to consider what *is* > changing? If it's just the output, and it's incorrect in version A and > correct in version B, then that sounds like a bug fix. If the output is > different in a meaningful way then maybe that's minor, maybe major. (I > would suggest that it's minor only if the output is definitely *better* in > every case with the new version, but can still be consumed in exactly the > same way) > > >> As a consumer of Cordova, you should be able to have some confidence that >> if there isn't a major version bump, you shouldn't need to change your >> calling code. >> >> > Absolutely. If any change to client code is required, there should be a > major version bump. (Within reason: any bug could be depended on by > someone; see https://xkcd.com/1172/) > > > >> 2) When doing an upgrade of plugins or platform, if there is a major >> version bump to any of those components, the CLI should make it really >> clear (a warning) that there may be a breaking change(s) and give them the >> opportunity to abort the upgrade. >> > > +1. We really need this. Maybe, like Debian, an upgrade should only ever > upgrade within the same major release, and a harder upgrade command would > be required for upgrading the major. > > Of course, this is all wishful thinking right now, since there's no upgrade > command at all. The "upgrade" path is currently "remove plugin; re-add > plugin", and I don't think that that flow should ever keep old metadata > around. > > >> 3) Keep the Upgrading Guides in the docs complete. So if they want to look >> at what needs to change, these docs should at least give them a feel for >> the order of magnitude, or better yet exactly what would be required. >> >> We are doing 1 & 3 already, correct? >> >> On Apr 28, 2014, at 2:49 PM, Josh Soref wrote: >> >>> Shazron wrote: >>> See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ >>> >>> While I h
Re: Some pain points from our users :'(
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 subprojects, *except* for the main platform's version number, which we've kind of declared to be a "marketing" version number. According to semver, the rule should be "No API changes with only a patch version bump. Only backwards-combatible API changes with a minor version bump." In practice, this means that the patch version gets incremented with bug fixes, and any *new* APIs can be added with a minor version increment. Any backwards-incompatible changes *require* a major 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. If the API signatures don't change, then we'd have to consider what *is* changing? If it's just the output, and it's incorrect in version A and correct in version B, then that sounds like a bug fix. If the output is different in a meaningful way then maybe that's minor, maybe major. (I would suggest that it's minor only if the output is definitely *better* in every case with the new version, but can still be consumed in exactly the same way) > As a consumer of Cordova, you should be able to have some confidence that > if there isn't a major version bump, you shouldn't need to change your > calling code. > > Absolutely. If any change to client code is required, there should be a major version bump. (Within reason: any bug could be depended on by someone; see https://xkcd.com/1172/) > 2) When doing an upgrade of plugins or platform, if there is a major > version bump to any of those components, the CLI should make it really > clear (a warning) that there may be a breaking change(s) and give them the > opportunity to abort the upgrade. > +1. We really need this. Maybe, like Debian, an upgrade should only ever upgrade within the same major release, and a harder upgrade command would be required for upgrading the major. Of course, this is all wishful thinking right now, since there's no upgrade command at all. The "upgrade" path is currently "remove plugin; re-add plugin", and I don't think that that flow should ever keep old metadata around. > 3) Keep the Upgrading Guides in the docs complete. So if they want to look > at what needs to change, these docs should at least give them a feel for > the order of magnitude, or better yet exactly what would be required. > > We are doing 1 & 3 already, correct? > > On Apr 28, 2014, at 2:49 PM, Josh Soref wrote: > > > 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 "iPhone"/"iPad", > > > > In principle, this would have been flagged to discourage updating the > > plugin, and in theory a solver could have identified the last version > from > > before this break. >
Re: Some pain points from our users :'(
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-filing.] Browsers change constantly. But they've standardized on a back button, a URL bar, some way to "go", bookmarks, saving, printing. There is nothing wrong with code changing. One other thing that the browser developers learned is that getting people to upgrade in baby steps results in fewer revolts. We've also seen the reverse in OS's, when MS failed to get people to migrate from 9x, or from XP, the pain of getting them to upgrade got worse and worse the longer they delayed. People who upgraded from Win 3.0 -> Win 3.1 -> Win 3.11 had minimal pain. Even 3.11 -> 95 wasn't terrible. People who upgraded 95 -> 98 -> Me (optional) | 2000 (optional) -> XP -> Vista -> 7 didn't have much pain. Going from 7 -> 8 -> 8.1 isn't bad either. Sometimes there's more of a change in a given thing, sometimes there's less. One trick MS used was to try to ensure certain things were consistent, e.g. If you were used to doing -r, or -e, those things worked from 95 -> 8.1. ,notepad, worked from Vista-> 8.1 (and if you had evolved your start menu in XP or older, something similar would have worked too). Migration tools help. MS actually generally puts them together, although I don't think it does a great job of getting people to use them. Tutorials and write-ups for workflows/changes also help. The migration guides that Cordova has had in prior versions were actually pretty impressive. And I hope that we can put together some automated tools to help w/ the future.
Re: Some pain points from our users :'(
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" changing also means people > cannot standardize on it and they look for something more > "stable"... The trick is to find that happy medium. > I know you're actively trolling, but I'll still comment on this. Some facts are important, and unlike you, I actually care about the facts: 1. The code isn't constantly changing. There's still a CLI-less workflow. You can use plugman to install plugins, or you can copy the Java classes manually and edit the config.xml so it works like the old project. This project may be more active than other projects, but my workflow for actually doing development on PhoneGap and Apache Cordova hasn't changed in almost four years. 2. The statements made above are absurd. It'd be amazing if Simon and I magically wrote the best code ever in PhoneGap 1.2 on Android, but I can tell you right now that version was garbage. That was code written back in November 2011. All minor versions before 2.x were done to ramp up to 2.0. We did a much better job ramping up to 3.0, but democracy and a bit of peer-pressure made sure that we changed a plugin API namespace at the last minute. That said, find and replace is trivial to do on all major IDEs and text editors, and isn't worth the rage that we've seen here. 3. We've kept 2.x support alive for six months before deprecating it. This was the last version before the pluggable module system. We have to move at the same pace as mobile, which luckily is slowing down, but is still ridiculously fast in comparison to server or desktop development. This means that we have to make sure that we're future-proof and that our code actually works with the latest SDKs while we try and add features and make mobile development actually easier. We've gone to great lengths to provide two methods for development, and while many people object to us providing both the CLI (which I recommend to our non-technical users currently) and plugman (which is easier than just copying over files), I think we're going to keep doing this for a long time to come, because of our users. Also, you have to be active when the decision is being made to have any impact in that decision. The namespace change was a terrible decision for so many reasons, since it was done to ease contributor pain at the cost of plugin developers. However, I was the only person in the discussion thread that pushed back against this, and I pushed against this as hard as I could. It's extremely hard for us to go back and reverse decisions once they've been made after a major release. Saying that your opinion matters a year after the fact is ridiculous, because not even my opinion mattered a year after the fact, other than the fact that I was there when it could have, and have it on the record.
Re: Some pain points from our users :'(
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 for something more "stable"... The trick is to find that happy medium. > > 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 compared to 3.x and if you are only updating YOUR userland > source once every 2 years and you don't expect it to be come with > problems?! The bugs found usually are not introduced by us but with Xcode, > iOS, or Android and we are FIXING those things with updates. > > Docs are a problem but as they say patches welcome. This is the sort of > entitled complaint that lead me off that list. > > > > On Mon, Apr 28, 2014 at 11:30 AM, Shazron wrote: > >> See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ >>
Re: Some pain points from our users :'(
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/commit/1beb1b5f6ac7470eb516768ef52ceda8df6278e1
Re: Some pain points from our users :'(
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 ' after adding a plugin is suggested but I don't see that documented in the Phonegap docs. Plus, that overwrites the www directory so it has to be copied beforehand which is troublesome if there are platform-specific customizations. (Is that the only time the outer www is used?) In addition, I didn't find documentation for the contents of cordova_plugins.js or the linkage between it and the plugin JS so I wasn't sure what was required and had to piece that together on my own. In the end, I manually updated cordova_plugin.js and the plugin JS files which is way more hairs than I think was intended. Overall, I still think Cordova is great framework but that improved documentation would go a long way towards making that more apparent. -Terence On 4/28/2014 2:15 PM, Michal Mocny wrote: 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 hasn't maintained his project for 2 years, hasn't read our docs, hasn't written tests to guard against platform assumptions, and expects to update everything in a few hours. There are a few issues he got hit with (plugin authoring with the CLI is a pain in the butt, 3.4 release plugin docs issue), but generally its probably not worth putting to much weight into it. More broadly, though, perhaps we should acknowledge that we will never catch all issues with releases and try to find ways to incentivize the community to help test out RC's for us? Perhaps a dedicated mailing list for known developers who stay bleeding edge that we email as part of starting the release vote process / at the end of [DISCUSS] thread? -Michal On Mon, Apr 28, 2014 at 2:54 PM, Shazron wrote: 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, for whatever reason, do not like that type of forum, but still choose the Google Groups. 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 appreciate that. I don't need to tell you guys that but 1.8 was a mess compared to 3.x and if you are only updating YOUR userland source once every 2 years and you don't expect it to be come with problems?! The bugs found usually are not introduced by us but with Xcode, iOS, or Android and we are FIXING those things with updates. Docs are a problem but as they say patches welcome. This is the sort of entitled complaint that lead me off that list. On Mon, Apr 28, 2014 at 11:30 AM, Shazron wrote: See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ
Re: Some pain points from our users :'(
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
Re: Some pain points from our users :'(
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 before today? Which commits > are you responsible for? I guess maybe you're new. https://groups.google.com/forum/#!topic/phonegap/1SqYdrR_3aE Look for "Blanchard" There's more work lying around on camera, file, etc. Just not lately. Like not since the acquisition by Adobe because I eventually got the idea things were too much in flux and that Nitobi wasn't really taking the project very seriously so I moved on for a bit. I do have three shipping products based on it though so I joined the mailing list to try to keep current. I've been here for over six months haven't said anything until today. I'm pretty much done commenting unless you have specific questions. I've said what I wanted to say. -Todd Blanchard
Re: Some pain points from our users :'(
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. As a consumer of Cordova, you >should be able to have some confidence that if there isn't a major >version bump, you shouldn't need to change your calling code. This is again the sort of thing I'm talking about, but it's pretty hard to do with a single number, and mostly useless. OTOH, with sufficient metadata to describe specific changes, it should work reasonably well. The problem is that there's *very* little that you can do to code which won't change someone's code. https://xkcd.com/1172/ If I fix the spelling of some output, it could break someone's parser. If I fix the spelling in some documentation, it could break someone's parser, or their test. If I change an image, it could break anything which expects a fixed size, fixed checksum, or fixed byte. A number really doesn't help people. The number will be "bigger", and probably "much bigger", what people need to know is "does this affect me". And ideally we can answer that for most cases. If I add a constant which is totally optional, then we can say "this probably won't affect you". If I add a constant which is needed to get behavior similar to past behavior, we can say "not having this constant in your code and using code before X will probably need a rethink". We're at the end of a release cycle, when we finish it, I'll try to post my metadata thoughts to the wiki. >2) When doing an upgrade of plugins or platform, if there is a major >version bump to any of those components, the CLI should make it really >clear (a warning) that there may be a breaking change(s) and give them >the opportunity to abort the upgrade. Last I checked, there was no way to update plugins, only remove them and add them again. But yes, my proposal would be a step to enable such a warning. It requires collecting metadata - which could be a problem. >3) Keep the Upgrading Guides in the docs complete. So if they want to >look at what needs to change, these docs should at least give them a feel >for the order of magnitude, or better yet exactly what would be required. > >We are doing 1 & 3 already, correct? I'm pretty sure we aren't doing a good job at 3. I don't use plugins much. I can say that it's pretty easy to not realize you've broken something, that happens a lot. Cordova-blackberry broke a whole bunch of (very poorly written) plugins because it fixed a bug in the exec bridge (the bridge is supposed to be async, but it wasn't, we made it async as per spec, but any plugin that assumed it was sync suddenly broke). A checklist which requires you to ask / consider metadata is one way that I hope we could improve this.
Re: Some pain points from our users :'(
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 beer. Plugman is consumed by the Cordova CLI. The CLI is for working with Cordova projects whereas Plugman is utilized for working with native platforms. (Just iOS for example.) Sometimes this is called 'separation of concerns'. Comments like "just building apps out here, its not rocket science" are harmful. I'm happy to help if you have a real issue but please consider there are a large number of people working very hard as volunteers and they don't need abuse. We do need help though. Your emails indicate you might want to. I'd recommend starting by reading up on wiki [1]. Even a failing test or reporting a bug for the issues (real issues) that you helps. Thanks! [1] http://wiki.apache.org/cordova/ContributorWorkflow 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. > > > 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 there is a phonegap cli tool and a cordova cli > tool and they work differently? Nevermind plugman which I totally can't > figure out. > > I don't even want cli tools. I don't care about them I was perfectly > happy doing git clones into a directory. I just want a well documented > directory structure and I'll put my stuff together thanks. > > None of my experiments with your cli tools and my own plugins have panned > out. In the end I end up with > a very custom XCode and/or Eclipse project that somehow I've made work via > various bits of lucky hackery. We're just building apps out here, its not > rocket science and if your users had a lot of free time on their hands, > they'd build native apps instead. Consider that. > > I think when you get to the point that you're writing software that writes > software you really need to take a step back and think about what you're > doing. > > >
Re: Some pain points from our users :'(
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 Jira issues. Anyhow, those changes mentioned by Todd before where either necessary and he just didn't have the context to know that, arrived at by public consensus, or manifest bugs which we fixed. If this thread was an issue I'd personally mark it as closed. On Mon, Apr 28, 2014 at 1:35 PM, 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. As a consumer of Cordova, you should be > able to have some confidence that if there isn't a major version bump, you > shouldn't need to change your calling code. > > 2) When doing an upgrade of plugins or platform, if there is a major > version bump to any of those components, the CLI should make it really > clear (a warning) that there may be a breaking change(s) and give them the > opportunity to abort the upgrade. > > 3) Keep the Upgrading Guides in the docs complete. So if they want to look > at what needs to change, these docs should at least give them a feel for > the order of magnitude, or better yet exactly what would be required. > > We are doing 1 & 3 already, correct? > > On Apr 28, 2014, at 2:49 PM, Josh Soref wrote: > > > 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 "iPhone"/"iPad", > > > > In principle, this would have been flagged to discourage updating the > > plugin, and in theory a solver could have identified the last version > from > > before this break. >
Re: Some pain points from our users :'(
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?
Re: Some pain points from our users :'(
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 there is a phonegap cli tool and a cordova cli tool and they work differently? Nevermind plugman which I totally can't figure out. I don't even want cli tools. I don't care about them I was perfectly happy doing git clones into a directory. I just want a well documented directory structure and I'll put my stuff together thanks. None of my experiments with your cli tools and my own plugins have panned out. In the end I end up with a very custom XCode and/or Eclipse project that somehow I've made work via various bits of lucky hackery. We're just building apps out here, its not rocket science and if your users had a lot of free time on their hands, they'd build native apps instead. Consider that. I think when you get to the point that you're writing software that writes software you really need to take a step back and think about what you're doing.
Re: Some pain points from our users :'(
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 on it. Furthermore, I wrote custom plugins on that api. They > still work. They are very fancy plugins. I don't care too much that you > made "architectural improvements" - from my perspective you just moved the > furniture around - nothing pre 2.0 was actually better in any way. Then > there's the gratuitous name change confusions that went on. Phonegap vs > Cordova changed a bunch of internal names for no really good reason. 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. > > Even Apple was smart enough not to change all their api prefixes from NS when > they bought NextStep. Gratuitous code breakage seemed to be the rule of the > day for awhile. You are aware that this is an Open Source project, right? > > K, that's ancient history but if you're feeling butt hurt about excessive > changes, I would like to point out that things looked very keystone cops from > the consumer's point of view prior to 2.0. Furthermore all this shifting > kept breaking third party plugins. We didn't have a proper API for plugins prior to 2.0. In fact, I would argue that our Java APIs are still not fully up to par. That being said, 2.0 brought the CordovaWebView feature, which allowed Android developers to embed the view, and set the framework for our third-party webview work that we're doing now to work around problems with the Android WebView. There are also the improvements to the Javascript bridge as well. If you don't feel that those were improvements, there's not much more we can say about that. > I get stuff has to progress but this: > > you will need to change the path to the following two classes within the Java > plugin code for android: > > 1 > 2 > import org.apache.cordova.api.CallbackContext; > import org.apache.cordova.api.CordovaPlugin; > -to- > > 1 > 2 > import org.apache.cordova.CallbackContext; > import org.apache.cordova.CordovaPlugin; > > This was necessary exactly - why? Its "nicer" I guess but you could have > lived with the extra level of indirection and not forced those of us who are > very busy to have to run around doing string replacement in our custom > plugins. This wasn't necessary and I was against it. However, since I was the only developer against it, we ended up adopting it. I already said "I told you so" a year ago, you saying it again is just as helpful. I would like to remind everyone of my favourite line the Apache Software Licence: 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. as well as this line in the MIT licence: THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. I think I'm just going to leave these here.
Re: Some pain points from our users :'(
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 Cordova, you should be able to have some confidence that if there isn't a major version bump, you shouldn't need to change your calling code. 2) When doing an upgrade of plugins or platform, if there is a major version bump to any of those components, the CLI should make it really clear (a warning) that there may be a breaking change(s) and give them the opportunity to abort the upgrade. 3) Keep the Upgrading Guides in the docs complete. So if they want to look at what needs to change, these docs should at least give them a feel for the order of magnitude, or better yet exactly what would be required. We are doing 1 & 3 already, correct? On Apr 28, 2014, at 2:49 PM, Josh Soref wrote: > 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 "iPhone"/"iPad", > > In principle, this would have been flagged to discourage updating the > plugin, and in theory a solver could have identified the last version from > before this break.
Re: Some pain points from our users :'(
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 new bugs. That's my perspective on it. Furthermore, I wrote custom plugins on that api. They still work. They are very fancy plugins. I don't care too much that you made "architectural improvements" - from my perspective you just moved the furniture around - nothing pre 2.0 was actually better in any way. Then there's the gratuitous name change confusions that went on. Phonegap vs Cordova changed a bunch of internal names for no really good reason. Even Apple was smart enough not to change all their api prefixes from NS when they bought NextStep. Gratuitous code breakage seemed to be the rule of the day for awhile. K, that's ancient history but if you're feeling butt hurt about excessive changes, I would like to point out that things looked very keystone cops from the consumer's point of view prior to 2.0. Furthermore all this shifting kept breaking third party plugins. For instance 1.4-1.5 http://simonmacdonald.blogspot.com/2012/04/migrating-your-phonegap-plugins-to.html And again when we hit 2.0 http://simonmacdonald.blogspot.com/2012/07/updates-to-plugins-for-phonegap-200.html And one more time for 3.0 http://devgirl.org/2013/09/05/phonegap-3-0-stuff-you-should-know/ I get stuff has to progress but this: you will need to change the path to the following two classes within the Java plugin code for android: 1 2 import org.apache.cordova.api.CallbackContext; import org.apache.cordova.api.CordovaPlugin; -to- 1 2 import org.apache.cordova.CallbackContext; import org.apache.cordova.CordovaPlugin; This was necessary exactly - why? Its "nicer" I guess but you could have lived with the extra level of indirection and not forced those of us who are very busy to have to run around doing string replacement in our custom plugins. I'm also not too fond of the introduction of not one but *two* sets of command line tools that are supposed to make managing plugins easy. They do the opposite. They generally terminate with incomprehensible errors and the barrier to writing my own plugins has gone stratospheric compared to what I had to do in 1.2. Furthermore...3.0 doesn't do much of anything from the developer's point of view that 1.2 didn't. So what is with all the changes? I'm not seeing the value. The same plugins ship, they do the same things, but you keep making this backwards incompatible and more and more complicated. Rant over. But I felt like it needed saying. -Todd Blanchard On 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 appreciate that. I don't need to tell you guys that but 1.8 > was a mess compared to 3.x and if you are only updating YOUR userland > source once every 2 years and you don't expect it to be come with > problems?! The bugs found usually are not introduced by us but with Xcode, > iOS, or Android and we are FIXING those things with updates. > > Docs are a problem but as they say patches welcome. This is the sort of > entitled complaint that lead me off that list. > > > > On Mon, Apr 28, 2014 at 11:30 AM, Shazron wrote: > >> See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ >>
Re: Some pain points from our users :'(
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 hasn't maintained his project for 2 years, hasn't read our docs, hasn't > written tests to guard against platform assumptions, and expects to update > everything in a few hours. > There are a few issues he got hit with (plugin authoring with the CLI is a > pain in the butt, 3.4 release plugin docs issue), but generally its > probably not worth putting to much weight into it. > > More broadly, though, perhaps we should acknowledge that we will never > catch all issues with releases and try to find ways to incentivize the > community to help test out RC's for us? Perhaps a dedicated mailing list > for known developers who stay bleeding edge that we email as part of > starting the release vote process / at the end of [DISCUSS] thread? > > -Michal > > > On Mon, Apr 28, 2014 at 2:54 PM, Shazron wrote: > >> 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, for whatever reason, do not like that >> type of forum, but still choose the Google Groups. >> >> >> >> >> 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 appreciate that. I don't need to tell you guys that but >> 1.8 >> > was a mess compared to 3.x and if you are only updating YOUR userland >> > source once every 2 years and you don't expect it to be come with >> > problems?! The bugs found usually are not introduced by us but with >> Xcode, >> > iOS, or Android and we are FIXING those things with updates. >> > >> > Docs are a problem but as they say patches welcome. This is the sort of >> > entitled complaint that lead me off that list. >> > >> > >> > >> > On Mon, Apr 28, 2014 at 11:30 AM, Shazron wrote: >> > >> > > See: >> https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ >> > > >> > >> > >
Re: Some pain points from our users :'(
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 against platform assumptions, and expects to update everything in a few hours. There are a few issues he got hit with (plugin authoring with the CLI is a pain in the butt, 3.4 release plugin docs issue), but generally its probably not worth putting to much weight into it. More broadly, though, perhaps we should acknowledge that we will never catch all issues with releases and try to find ways to incentivize the community to help test out RC's for us? Perhaps a dedicated mailing list for known developers who stay bleeding edge that we email as part of starting the release vote process / at the end of [DISCUSS] thread? -Michal On Mon, Apr 28, 2014 at 2:54 PM, Shazron wrote: > 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, for whatever reason, do not like that > type of forum, but still choose the Google Groups. > > > > > 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 appreciate that. I don't need to tell you guys that but > 1.8 > > was a mess compared to 3.x and if you are only updating YOUR userland > > source once every 2 years and you don't expect it to be come with > > problems?! The bugs found usually are not introduced by us but with > Xcode, > > iOS, or Android and we are FIXING those things with updates. > > > > Docs are a problem but as they say patches welcome. This is the sort of > > entitled complaint that lead me off that list. > > > > > > > > On Mon, Apr 28, 2014 at 11:30 AM, Shazron wrote: > > > > > See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ > > > > > >
Re: Some pain points from our users :'(
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 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, for whatever reason, do not like that > type of forum, but still choose the Google Groups. > > > > > 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 appreciate that. I don't need to tell you guys that but > 1.8 > > was a mess compared to 3.x and if you are only updating YOUR userland > > source once every 2 years and you don't expect it to be come with > > problems?! The bugs found usually are not introduced by us but with > Xcode, > > iOS, or Android and we are FIXING those things with updates. > > > > Docs are a problem but as they say patches welcome. This is the sort of > > entitled complaint that lead me off that list. > > > > > > > > On Mon, Apr 28, 2014 at 11:30 AM, Shazron wrote: > > > > > See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ > > > > > >
Re: Some pain points from our users :'(
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, for whatever reason, do not like that type of forum, but still choose the Google Groups. 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 appreciate that. I don't need to tell you guys that but 1.8 > was a mess compared to 3.x and if you are only updating YOUR userland > source once every 2 years and you don't expect it to be come with > problems?! The bugs found usually are not introduced by us but with Xcode, > iOS, or Android and we are FIXING those things with updates. > > Docs are a problem but as they say patches welcome. This is the sort of > entitled complaint that lead me off that list. > > > > On Mon, Apr 28, 2014 at 11:30 AM, Shazron wrote: > > > See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ > > >
Re: Some pain points from our users :'(
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 appreciate that. I don't need to tell you guys that but 1.8 > was a mess compared to 3.x and if you are only updating YOUR userland > source once every 2 years and you don't expect it to be come with > problems?! The bugs found usually are not introduced by us but with Xcode, > iOS, or Android and we are FIXING those things with updates. > Dude, this is the #1 complaint I get from everyone who uses our stuff. Our users don't have massive dev teams to deal with the changes that we do. Often, the same dev who is working on the PhoneGap app is also doing the backend work, most likely maintaining some broken-ass Rails 2 system, and probably works stupid long days for mediocre pay, or equity in a startup which may never ship anything. We can't solve those problems, because most of those are probably poor life choices, but we should be able to tell people how to migrate from old and broken to new and mostly working and point out some pain points. That said, I think that having an LTS is absolutely stupid given that six years ago, Mobile wasn't really a thing, and two years ago, Jellybean just started to exist. Perhaps when mobile starts to slow down a bit more, this might make sense, but I highly doubt it. > Docs are a problem but as they say patches welcome. This is the sort of > entitled complaint that lead me off that list. > These still are our users, and they're probably the majority of our users, whether we like them or not. I don't like these people, but their complaints aren't totally without merit. > > > On Mon, Apr 28, 2014 at 11:30 AM, Shazron wrote: > >> See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ >>
Re: Some pain points from our users :'(
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 "iPhone"/"iPad", In principle, this would have been flagged to discourage updating the plugin, and in theory a solver could have identified the last version from before this break. > Cordova/Phonegap docs where no help, because the version 3.4.0 version >of the docs has broken links for all the plugins api docs. This is a release process issue. We shouldn't have allowed the release to happen w/ this broken. At least one of Edge or release-version should always work. > I then installed the "status bar" plugin for the ios 7 status bar. This >plugin didn't work either. I always get an error in the XCode console >that one or the other plugin does not exist or isn't cdv plugin... I think this was the Xcode 5.1 bug, which I think we should have (process) released the fix for sooner.
Re: Some pain points from our users :'(
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, if Adobe was, we wouldn't be here). Seriously though, the upgrade path between 2.1 and 3.x is so painful, you have to tell people to throw everything out but their HTML/JS/CSS and start over. Make sure when they throw everything out that they throw out phonegap.js/cordova.js as well. On Mon, Apr 28, 2014 at 11:30 AM, Shazron wrote: > See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ
Re: Some pain points from our users :'(
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 compared to 3.x and if you are only updating YOUR userland source once every 2 years and you don't expect it to be come with problems?! The bugs found usually are not introduced by us but with Xcode, iOS, or Android and we are FIXING those things with updates. Docs are a problem but as they say patches welcome. This is the sort of entitled complaint that lead me off that list. On Mon, Apr 28, 2014 at 11:30 AM, Shazron wrote: > See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ >
Some pain points from our users :'(
See: https://groups.google.com/d/msg/phonegap/II0qo-dSFWs/Fj8jkemGSbUJ