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 <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.
