If you're interested in this I think it'd be best to look at the --experimental "plugin save" and "plugin restore" commands and try to iterate from there.
On Wed, Jul 23, 2014 at 5:21 PM, Carlos Santana <[email protected]> wrote: > +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.json > { > cordova: "3.7.1-0.3.7", > > platforms:[{name:"cordova-ios",version:"3.6.1"},{name:"cordova-blackberry",version:"3.7"}] > > plugins:[{id:"org.apache.cordova.console",version:"0.1.2"},{id:"com.ibm.myplugin",version:"0.1.1"}] > } > > 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 <[email protected]> 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 <[email protected]> > > 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 > <[email protected]> >
