cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Cordova-CLI: Version handling
Date Fri, 18 Jan 2013 17:55:17 GMT
Cool, thanks for the feedback everyone! Sounds like downgrading won't be
supported for now.

On 1/18/13 9:07 AM, "Marcel Kinard" <cmarcelk@gmail.com> wrote:

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

It's the (b) case. The major + point release of the CLI tools follow
Cordova's. So 2.3.x of cli will work with cordova 2.3.x. 2.4.x of cli will
work with cordova 2.4.x.

With that requirement in mind, upgrading a project from 2.3 to 2.5 *could*
look like this:

- user currently running cli 2.3.x and has a 2.3.x cordova project
- users run the upgrade command (say, `cordova upgrade 2.5.0`)
- tool sees if there is a 2.5.x version of itself available. If no, errors
out.
- cli tools upgrade themselves to 2.4.x.
- cli tools run project-level, platform-specific `upgrade` scripts for
each added platform to the project, to get them to 2.4.x. If unsuccessful,
errors out (and hopefully returns state of project back to what it was)
- cli tools upgrade themselves to 2.5.x.
- tools run the upgrade script to move project to 2.5.x.

One thing that strikes me as bad in this case is that the cli tools become
a global dependency. If you are managing multiple cordova projects that
use different cordova versions, it would be tricky to try to support both
projects simultaneously. Are we going up a slippery slope here?


Mime
View raw message