cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Soref <>
Subject Re: Some pain points from our users :'(
Date Mon, 28 Apr 2014 21:25:46 GMT
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.

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.

View raw message