I would not be able to join the Friday hangout, but here are my main concerns -
I agree that it would be best to always give the users the latest version of the platform and keeping it independent of the CLI. However, given that Cordova now also caters to enterprise users, backwards compatibility and reproducible dev environment. The question would be - what should be the default behavior? When a new user downloads the CLI and then creates a project, we could download the latest versions, but will they always be saved in the config.xml so that they can be restored? Does it not make more sense to semver them to ensure that breaking changes do not impact users who do not want to upgrade their projects? Asking users to change config.xml if they need to preserve platforms every time may not be a good default. Does this change also mean that every release of the Cordova CLI will be tested against multiple versions of the platforms? In case of Visual Studio, a version of CLI is bundled with the tools and the user cannot choose any other version. This simplifies issues with support and is a guarantee that the specific version of the CLI works with a specific version of VS tools. Visual Studio and Cordova have different release timings and would it always be possible to guarantee that a newer version of the CLI works with an older version of the VS tools? -----Original Message----- From: Jesse [mailto:[email protected]] Sent: Wednesday, July 23, 2014 10:47 AM To: [email protected] Subject: Re: Proposal: remove platform versions from platfroms.js Yeah, let's discuss the full impact on Friday. @purplecabbage risingj.com On Wed, Jul 23, 2014 at 7:36 AM, Michal Mocny <[email protected]> wrote: > This sounds like a great topic for hangout Friday. Glad to have a > concrete proposal / some counter arguments to discuss. > > > On Wed, Jul 23, 2014 at 10:22 AM, Mark Koudritsky <[email protected]> > wrote: > > > > > > > Currently WebWorks ships specific versions of things. > > > If we had shipped unpinned versions of stuff, then eventually we > > > would have created projects which our UI wouldn't have recognized > > > as valid (because, they e.g. Didn't have a ".cordova", or a > > > "hooks", or a > "merges" > > > or whichever things we had been using to determine if a project > > > was > > valid). > > > > > > > As long as you continue to ship a version of cordova-backberry > > bundled > with > > WebWorks, it won't be affected by the change I propose. CLI will use > > that bundled version just like it does now using the settings in > > .cordova/config.json. We do the same thing with cca. > > > > If in the future you decide to stop bundling cordova-blackberry with > > WebWorks and switch to the npm published versions, I see several > > good > ways > > for doing that, but in any case, you will probably want to expose > > the version (or range of versions) to use as a user editable setting. > > >
