On Tue, Apr 29, 2014 at 4:12 PM, Joe Bowser <bows...@gmail.com> wrote:
> +1 to this post, who wants to take this on? > > On Tue, Apr 29, 2014 at 12:22 PM, Joerg Holz <h...@hamburg.de> 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 <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 > > -------------------------------------------------------- > > >
