cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: Proposal: remove platform versions from platfroms.js
Date Wed, 23 Jul 2014 18:49:23 GMT
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) <
panarasi@microsoft.com> 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:anis.kadri@gmail.com]
> Sent: Wednesday, July 23, 2014 10:54 AM
> To: dev@cordova.apache.org
> 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 <mmocny@chromium.org> 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 <kamrik@google.com>
> > 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.
> > >
> >
>

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