cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse MacFadyen <purplecabb...@gmail.com>
Subject Re: Cordova-CLI: Version handling
Date Fri, 18 Jan 2013 17:26:55 GMT
-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 <mmocny@chromium.org> wrote:

On Thu, Jan 17, 2013 at 8:05 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> 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.


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 <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
View raw message