cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: Some pain points from our users :'(
Date Tue, 29 Apr 2014 20:12:35 GMT
+1 to this post, who wants to take this on?

On Tue, Apr 29, 2014 at 12:22 PM, Joerg Holz <holz@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.
>
> 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 <iclelland@chromium.org>:
>
>> Sorry, I'm a little late to the party here...
>>
>>
>> On Mon, Apr 28, 2014 at 4:35 PM, Marcel Kinard <cmarcelk@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 <jsoref@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
> holz@hamburg.de
>
> NEU: doreport - die Reportingsoftware:
> http://www.doreport.de
> --------------------------------------------------------
>

Mime
View raw message