Hey Chuck, thanks for joining the conversation! Great to have all stakeholders taking part.
On Wed, Jul 23, 2014 at 9:40 PM, Chuck Lantz <cla...@microsoft.com> wrote: > Hey folks, I'm on the Visual Studio team. I think my primary concern here > comes more from what we expect developers to understand and the loss of > predictability. If you go to the Cordova documentation and see "Cordova > 3.5.0", and then grab the CLI, that comes with a certain set of > assumptions. A Cordova version is very much a "thing" right now even if > the pieces and parts underneath are much more independent. So, as a > developer, my frame of reference when I go and grab Cordova tools and add > 3.5.0, I get 3.5.0 for each platform I add. If I then go create another > project, I'd expect to get the exact same thing - bugs and all. If we lose > that as an anchor concept, I think we'll quickly loose developers new to > the ecosystem. (Note that from a pure VS perspective, we could layer a > concept on top to solve this if required as Andrew pointed out.) > I completely agree that by dropping the idea of a Cadence Version, that we do lose a nicety. The question in my mind is whether the advantages make it worth it. For docs, it's easy enough to stop generating "versioned" docs, and just be sure to keep them up to date with "Added in Android 4.0", "Removed in iOS 3.6" kind of messages. > > Now, even pinning to 3.5 and ignoring ".0" has issues since platforms can > version independently and likely with little notice from a developer > standpoint. Even if a platform update just fixes a bug, it hurts > predictability. Devs will end up trying to figure out why a problem > happens in one of their 3.5.0 projects and not the other. Regressions can > also happen, so new problems can surface on a newer project which I think > is equally confusing. > To Mark's point, how are platforms different from plugins? Right now CLI pulls latest plugin versions by default, so how do you deal with that re: predictability? > > To be clear, I love idea of being able to pull newer versions of a > platform and I definitely would love to see fixes be released faster. > However, I not see that 3.5.0-0.2.6 was allowing you to do "platform add > android@3.5.1"? > Hmm, "platform add android@3.5.0" works fine using CLI@master. @3.5.1 wouldn't work because there is no 3.5.1 yet. > > -Chuck > > -----Original Message----- > From: Carlos Santana [mailto:csantan...@gmail.com] > Sent: Wednesday, July 23, 2014 2:27 PM > To: dev@cordova.apache.org > Subject: Re: Proposal: remove platform versions from platfroms.js > > I forgot to mention but agree with suggestion of having a local version of > cordova cli saved in node_modues, and that the default cordova behavior > will be to look first in local node_modules for cordova cli and if it found > use that one, if not then use global one. same as grunt-cli > > > > On Wed, Jul 23, 2014 at 5:21 PM, Carlos Santana <csantan...@gmail.com> > 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-blackbe > > rry",version:"3.7"}] > > > > plugins:[{id:"org.apache.cordova.console",version:"0.1.2"},{id:"com.ib > > m.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 <mmo...@chromium.org> > 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 <kam...@google.com> > >> 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 > > <csantan...@gmail.com> > > > > > > -- > Carlos Santana > <csantan...@gmail.com> >
