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.
