I agree, there are many cases where this will lead to complete un-predictability, and it is still unclear who this 'feature' benefits.
How can we guarantee that latest version of a newly added platform supports all the same plugins of the previously added platforms? I think ultimately the only benefit is to give us some flexibility with release schedules, but I would much rather have us focus on just releasing everything more often. Historically we have never been able to deliver a patched point release in under a month, so assuming we can get back to releasing every month, all would be fine, and the train could just keep rolling forwards. Predictably! @purplecabbage risingj.com On Wed, Jul 23, 2014 at 10:59 AM, Parashuram Narasimhan (MS OPEN TECH) < [email protected]> wrote: > I was thinking platforms are devDependencies and plugins are dependencies > :) > > In a way, that’s how the bundling works - plugins are packaged with the > app, while platforms are only needed during development !! > > -----Original Message----- > From: Anis KADRI [mailto:[email protected]] > Sent: Wednesday, July 23, 2014 10:54 AM > To: [email protected] > Subject: Re: Proposal: remove platform versions from platfroms.js > > +1 for package.json for platforms. plugins might a bit trickier but > +still > doable, we could get rid of plugins/ but we somehow need to keep track of > them in node_modules/ (maybe use one of the 10 config files we have). > Platforms in package.json should cause no problems though, add/remove > platforms, pin/unpin versions if required. > > > 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. > > > > > >
