cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Kinard <cmarc...@gmail.com>
Subject Re: Cordova-CLI: Version handling
Date Fri, 18 Jan 2013 17:07:51 GMT
As a data point, this week I talked to a Cordova user who recently 
published their app to the stores for iOS, Android, and Blackberry. I 
asked him about his experience with Cordova, and one complaint was 
around doing Cordova upgrades - he basically would start with a brand 
new empty Cordova project in the IDE and then lay down his unchanged 
application files, it's the opposite of laying down the new Cordova 
files in the existing application project. I'm not saying it's not 
possible, just that he had a bad experience with the upgrade 
instructions in the doc and didn't trust an in-place upgrade. So if we 
can get him to have a good experience with doing upgrades using the CLI, 
that would be very cool.

On the plus side, he was very happy to basically single-source his app 
across those three platforms.

On 1/17/2013 3:17 PM, Filip Maj wrote:
> On 1/17/13 11:57 AM, "Andrew Grieve"<agrieve@chromium.org>  wrote:
>> The thing I'd be afraid of with a script, is if they've modified their
>> CordovaLib or their CordovaLib.xcodeproj in any way. Maybe we can just
>> mitigate this by showing them a warning and a confirm prompt before going
>> ahead with it?
I like Andrew's idea of checksumming the files and displaying a 
warning/confirmation that their mods are going to be lost. I worked on 
building an appliance SDK, and we were constantly surprised at how many 
customers were hacking the SDK to twiddle things they weren't supposed 
to in order to get an unsupported customization. If they would have just 
asked, we could have made it configurable, but apparently asking is the 
last resort, kinda like guys reading the owner's manual. ;-)
>> I don't think we should put effort into downgrading. People should be
>> using
>> source-control for that.
I also suggest that downgrades not be supported in the tool. Keep it 
simple, and move users forward. I worked on appliance firmware doing 
downgrades, and it was a major pain. Run away! ;-) However, doing an 
upgrade would be one of the main benefits.
>> I think
>> I'd like it to work so that cordova-cli *is* versioned along with the rest
>> of it, but that it would work with older cordova projects without forcing
>> them to upgrade.
> Not sure if this is doable. The maintenance necessary to maintain old
> cordova structures would be a lot of work. For example, plugins.xml vs.
> config.xml support. Not only did we change the name, but now the structure
> is diverging greatly from what this file used to be.
This is an interesting topic. So is the model that (a) the versioning of 
the CLI floats separate from Cordova, and the CLI needs to know how to 
deal with all (well, everything after 2.3) versions of Cordova, or (b) 
the CLI is versioned tightly with Cordova, and needs to know how to deal 
only with that version of Cordova (well, and how to migrate forward from 
version n-1)? I would suggest the latter, as it would simplify a lot. If 
someone wants to install version x.y of Cordova, then they would need 
version x.y of the CLI, even if it x.y is not the latest version of the 
CLI. In a worst case scenario, if someone wants to upgrade from 2.5 to 
2.7, they would also need to run the 2.6 upgrader - yeah, it's 
inconvenient, but it becomes more predictable to execute on.

-- Marcel Kinard

Mime
View raw message