I'm definitely in favour of not pinning the version, since I think that will significantly simplify the release process.
re webworks - not sure I fully understood the things you wanted to think about there, but I'm sure it would be easy to have downstreams pin versions. You can already override where CLI looks for platforms using .cordova/config.json or the JS API equivalent. re Visual Studio - again, I don't fully know how this integration works, but sounds like right now your users can choose the version of CLI to use? Instead - how about just always using the latest version of CLI and have them choose the version of the platform to use? re Recreating platforms - Gorkem added an experimental feature for saving & restoring platforms to config.xml. I think it still needs a bit of work, but I think this approach makes sense and we should pursue it. re package.json - I think the idea definitely a good one, but I think our tools pretty much already support this use-case via "cordova platform add node_modules/cordova-android". Perhaps we could add the equivalent of plugins_search_path for platforms so that it automatically looks within node_modules? Either way - I like supporting this flow, but I don't think we should move to only support it since it's easy to get what's in your node_modules mismatching what's in your platforms/ On Tue, Jul 22, 2014 at 6:45 PM, Parashuram Narasimhan (MS OPEN TECH) < panar...@microsoft.com> wrote: > Always downloading the latest will also be a problem for Visual Studio > that uses Cordova as the IDE. > > We would need a way where if 2 developers checkout the project and use a > specific version of Cordova (CLI), they should have the same version of > platform too. Given that the version of the platforms is not picked up from > any place in the project and is explicitly specified only in the CLI, this > would be hard. > > If a user does not check in the platform versions, how will be they able > to recreate the platforms again ? > > A random idea - how about we treat Cordova projects like a NodeJs project. > Cordova is much like a "build system" (think Grunt). There is a > package.json (another config file, sign :( ) that specifies the version of > platforms and plugins that this Cordova platform needs. This would be like > how Grunt version is specified in package.json. The Cordova-cli would be > like Grunt-cli. This way, plugin and platforms can simply be installed > using npm and are treated just like packages to "build" an app. > > -----Original Message----- > From: Josh Soref [mailto:jso...@blackberry.com] > Sent: Tuesday, July 22, 2014 3:06 PM > To: dev@cordova.apache.org > Subject: Re: Proposal: remove platform versions from platfroms.js > > Mark Koudritsky wrote: > >As the next step in decoupling platform releases I would like to remove > >the hard-coded version in platform.js and let the CLI to download the > >latest platform version available on npm by default. > > As long as the file will continue to support pinned versions… > > I'm not quite sure where I stand on this as a default behavior. > > 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). > > The second version of the problem is that I'd sort of like to be able to > /think/ about letting webworks users get newer versions of > cordova-blackberry w/o necessarily having to install a new "webworks". > (This is sort of the opposite of the previous one) > > The third, is that I might want to have distinct version series for > webworks based things and cordova based things (I'm not really sure on this > point). > > One approach is to rely on api versioning so instead of platform = 3.5 -> > 3.6 -> 3.7, we could have platform = 3.5:3.5 -> 3.5:3.6, where the major > number is a cli version. That would in theory let me offer different > versions of the platform to a cli w/o giving it a version that will just > break it. > > >- It will hit the network for every "platform add" that has no version > >explicitly specified. In most cases the reply from npm will be an "HTTP > >304 > >- Not Modified". > > - We'll have to add in some sort of check that the version of CLI that > >you have works with the platform. E.g. current tools might not work > >with cordova-5.0. In than case we can display an error that instructs > >the user to either upgrade CLI or specify the platform version > >explicitly. > > Not a big fan of this "specify explicitly" nor "command line", webworks is > often used w/ a GUI (well, we ship one, I'm not sure how often it's used…). > > WebWorks also ships its own version of cordova-blackberry, which isn't > precisely the same as the version that's in the registry. I'm not sure I'd > want to have to hit the network for this. At the very least, I'd like > information about how to cache our version into the cache so at least > something is present. > >
