cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Parashuram Narasimhan (MS OPEN TECH)" <>
Subject RE: Proposal: remove platform versions from platfroms.js
Date Tue, 22 Jul 2014 22:45:32 GMT
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 [] 
Sent: Tuesday, July 22, 2014 3:06 PM
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
>- 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 

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.

View raw message