cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Cordova-CLI: Version handling
Date Fri, 18 Jan 2013 18:13:46 GMT
Seems really slippery to me. Lets keep this one in the backlog while
we shore up the supporting tools for plugins, etc.

On Fri, Jan 18, 2013 at 9:55 AM, Filip Maj <fil@adobe.com> wrote:
> 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