cordova-dev mailing list archives

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message