-1 downgrading Re: local git repo - I would hope/expect that the project is already under version control.
Cheers, Jesse Sent from my iPhone5 On 2013-01-18, at 6:46 AM, Michal Mocny <[email protected]> wrote: On Thu, Jan 17, 2013 at 8:05 PM, Andrew Grieve <[email protected]> wrote: > On Thu, Jan 17, 2013 at 3:17 PM, Filip Maj <[email protected]> wrote: > >> >> >> On 1/17/13 11:57 AM, "Andrew Grieve" <[email protected]> wrote: >> >>> 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? >> >> If they've modified it then I think expecting a stock upgrade or > downgrade >> script to work is unrealistic. We can't solve all possible problems our >> users will encounter.. > Yeah, ideas along these lines would be to do store checksums of the files > when installing, and then using those to see if any have changed. If > they've changed, then do a silent update, if they *have* changed, then show > a warning prompt and blow away their changes. A warning every time would > likely be fine too, since the "use source control" argument applies here > too. What about just initializing a local git repo (I cannot recall if cli was to depend on git or not already?). This has the added advantage that we can checkout user changes into a branch, upgrade, and then give them the option to rebase. > > >> >>> 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? >> >> Agree but wanted to open up the discussion anyways. -1 to downgrade support. >>> Fil, what are your thoughts around versioning the cordova-cli tool? >> >> Yep. The tools are now following the point releases of the main project > as >> of 2.3. However, the patch revision for the CLI tools are on their own >> track. This way I can roll out fixes and updates quickly, on a > per-release >> basis. I think currently the tools are at 2.3.4 since I committed four >> patches since enabling support for cordova 2.3.0. Make sense? > > Makes sense! > > >> >>> 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. > > Good point. Might be too early to tell if this will be important or not, > but it might be worth making it so that multiple versions can be installed. > e.g. If a user has multiple projects running on different versions of > Cordova. Maybe if we allow this, we could even have the tools detect the > version and just pass through calls to the correct version of the CLI > tools? Either way not something we have to support from the get-go. > > >> >>> >>> >>> >>> >>> >>> >>> >>> 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? >
