cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <>
Subject Re: Proposal: remove platform versions from platfroms.js
Date Wed, 23 Jul 2014 21:21:07 GMT
+1 on removing the pining

Can we at least record what's get's installed in a single place?
This will help if someone is trying to debug a problem, it will be easy to
tell what are the components and their levels being use.

Meaning a the minimum recording platforms, plugins, and latest cli version
used on the project.
Meaning every time you add a platform or plugin update cordova.json,
everytime you run a cordova command like "cordova prepare"
cordova: "3.7.1-0.3.7",

I prefer cordova.json on the root, and if not present look for a "cordova"
object in package.json

After this is done, we can discuss how this information can be use by the
tool if at all like implementing a "cordova install" that reads the file,
or a "cordova outdated" that reads the file, and so on.. of course without
re implementing the wheel and leveraging "npm" and "node_modules" directory

Also work towards making the cli so so unaware about the platforms, that
adding a new platform "cordova-xphone" the cli will not need to change.
Then the problem about what cli version works with what version of the
platform becomes a mute point.

On Wed, Jul 23, 2014 at 4:50 PM, Michal Mocny <> wrote:

> I think Mark summarizes my thoughts as well.
> We're overdue brainstorming what we want cordova workspaces to look like
> (package.json, app manifests / config files, grunt/gulp integration,
> browserify, directory structure..).  I don't think even the full hour on
> this weeks hangout would suffice for this, so we should probably organize
> something specifically for this topic for another date.  I don't think we
> should be making any significant changes to users' cli workflow until we
> figure out where we actually want to end up (and worry thats what we are
> doing with the current package.json proposals).
> For the purpose of this week we should have the goal of figuring out:
> - What behaviour do users expect (Please not "what is the current behaviour
> and why it cannot change")
> - How to simplify releasing platforms
> - How/when to (properly) pin down versions of all cordova bits
> -Michal
> On Wed, Jul 23, 2014 at 4:30 PM, Mark Koudritsky <>
> wrote:
> > Part of the discussion is release flexibility vs predictability. My main
> > problem is that currently we have neither. By default CLI downloads
> pinned
> > versions of platforms but latest versions of plugins.
> >
> > Changing the concept of corodva project to something managed by npm is an
> > interesting idea but it requires much much more than just adding a
> > package.json file and is not a short term thing. I think it deserves a
> > separate discussion.
> >

Carlos Santana

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