cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Cordova-CLI: Version handling
Date Fri, 18 Jan 2013 01:05:53 GMT
On Thu, Jan 17, 2013 at 3:17 PM, Filip Maj <fil@adobe.com> wrote:

>
>
> On 1/17/13 11:57 AM, "Andrew Grieve" <agrieve@chromium.org> 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.



>
> >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.
>
> >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 <fil@adobe.com> 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?
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message