Looking at iOS as an example: To do an upgrade: 1. Close xcode 2. Delete CordovaLib & CordovaLib.xcodeproj 3. Copy in new CordovaLib & CordovaLib.xcodeproj
Sometimes: - Add extra frameworks to your App's target 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 don't think we should put effort into downgrading. People should be using source-control for that. Again though, a warning message + confirm prompt should suffice here? Fil, what are your thoughts around versioning the cordova-cli tool? 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. On Thu, Jan 17, 2013 at 2:15 PM, Filip Maj <[email protected]> wrote: > Questions: how to handle moving between cordova versions? Do we want to > support both upgrading and downgrading? How to land support for this in > cordova-cli? > > My answers: > > - how to handle moving between cordova versions? > Suggestion: add an "upgrade" (and "downgrade") script to each platform > implementation, which handles moving from the previous version to the > current and vice-versa. > - Do we want to support both upgrading and downgrading? > IMO: Yes. > - How to land support for this in cordova-cli? > > CLI tools shell out to above-mentioned scripts. > > In my mind we would draw a line in the sand (let's say, 2.4, or 2.5) on > which Cordova version(s) support upgrade and downgrade scripts. From that > point on we can tell our users "OK, if you run 2.4 (or 2.5) or newer, you > can use these scripts. Or you can use cordova-cli if you want a unified > tool for this. If you are below this version, take a look at the > "Upgrading" guides written for the platforms in the docs." > > Thoughts? Any other suggestions? > >
