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 <iclell...@chromium.org>: > Sorry, I'm a little late to the party here... > > > On Mon, Apr 28, 2014 at 4:35 PM, Marcel Kinard <cmarc...@gmail.com> 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 <jso...@blackberry.com> 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. >> -------------------------------------------------------- Jörg Holz | +49-175-640 35 80 h...@hamburg.de NEU: doreport - die Reportingsoftware: http://www.doreport.de --------------------------------------------------------
