You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Filip Maj <fi...@adobe.com> on 2013/01/17 20:15:53 UTC
Cordova-CLI: Version handling
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?
Re: Cordova-CLI: Version handling
Posted by Jesse MacFadyen <pu...@gmail.com>.
-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 <mm...@chromium.org> wrote:
On Thu, Jan 17, 2013 at 8:05 PM, Andrew Grieve <ag...@chromium.org> wrote:
> On Thu, Jan 17, 2013 at 3:17 PM, Filip Maj <fi...@adobe.com> wrote:
>
>>
>>
>> On 1/17/13 11:57 AM, "Andrew Grieve" <ag...@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 <fi...@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?
>
Re: Cordova-CLI: Version handling
Posted by Michal Mocny <mm...@chromium.org>.
On Thu, Jan 17, 2013 at 8:05 PM, Andrew Grieve <ag...@chromium.org> wrote:
> On Thu, Jan 17, 2013 at 3:17 PM, Filip Maj <fi...@adobe.com> wrote:
>
> >
> >
> > On 1/17/13 11:57 AM, "Andrew Grieve" <ag...@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 <fi...@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?
> > >>
> > >>
> >
> >
>
Re: Cordova-CLI: Version handling
Posted by Andrew Grieve <ag...@chromium.org>.
On Thu, Jan 17, 2013 at 3:17 PM, Filip Maj <fi...@adobe.com> wrote:
>
>
> On 1/17/13 11:57 AM, "Andrew Grieve" <ag...@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 <fi...@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?
> >>
> >>
>
>
Re: Cordova-CLI: Version handling
Posted by Shazron <sh...@gmail.com>.
One problem with upgrade scripts is some do modify the native code in their
app template (AppDelegate.m / MainViewController.m in iOS for example) --
how would we handle those?
I would think we would just report merge conflicts and let the devs
manually resolve? That's one thing - but potentially modifying devs'
existing code can be problematic.
I have some ideas how to mitigate this if we decide to go this route: e.g
rename existing code method names that are updated in a new version (that
have been modified in the dev's existing project), inject the updated code
method, let the dev resolve later the differences. Their old code is still
there, we don't really touch it.
On Fri, Jan 18, 2013 at 11:35 AM, Anis KADRI <an...@gmail.com> wrote:
> On Fri, Jan 18, 2013 at 9:55 AM, Filip Maj <fi...@adobe.com> wrote:
>
> > 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?
> >
>
> With the current architecture, I believe it should upgrade all or none.
> Dealing with multiple cordova app versions within the same project is
> tricky and error prone.
> Side note: This is one of the reasons why having apps self-contained in a
> project vs separate can be an issue and why I wanted the cli tool to deal
> with apps independently.
>
> I agree that platform maintainers should start writing upgrade scripts
> (from one version to the version immediately after) instead of upgrade
> guides. The CLI would consume them.
>
> I also agree that downgrades should not be available.
>
> One tricky point as far as upgrades are concerned is plugins. How to
> upgrade them with Cordova versions ? Will they work properly if/when
> Cordova gets updated to a newer version ? Should the plugin spec be updated
> to reflect multiple cordova versions support ?
>
Re: Cordova-CLI: Version handling
Posted by Filip Maj <fi...@adobe.com>.
On 1/18/13 11:35 AM, "Anis KADRI" <an...@gmail.com> wrote:
>On Fri, Jan 18, 2013 at 9:55 AM, Filip Maj <fi...@adobe.com> wrote:
>
>> 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?
>>
>
>With the current architecture, I believe it should upgrade all or none.
>Dealing with multiple cordova app versions within the same project is
>tricky and error prone.
That's not on the table. I wasn't talking about handling different cordova
versions within one project (I.e. Android running 2.3 vs iOS running 2.4).
I was talking about having separate projects running different cordova
versions. This problem should be solved first before attempting to solve
different versions of cordova used in the same project for different
platforms.
>I agree that platform maintainers should start writing upgrade scripts
>(from one version to the version immediately after) instead of upgrade
>guides. The CLI would consume them.
Sweet. When does the group thinkg we should we start doing this? 2.4.0rc1?
>One tricky point as far as upgrades are concerned is plugins. How to
>upgrade them with Cordova versions ? Will they work properly if/when
>Cordova gets updated to a newer version ? Should the plugin spec be
>updated
>to reflect multiple cordova versions support ?
Doesn't the spec already support specifying which version of cordova it
works against? If not, it definitely should. Where are we keeping track of
the spec?
As for what to do with plugins when upgrading.. Hmm. Naïve first step:
plugman --remove it, run the upgrade script, plugman --add it back in? If
it errors it errors, let the user figure it out?
Re: Cordova-CLI: Version handling
Posted by Anis KADRI <an...@gmail.com>.
On Fri, Jan 18, 2013 at 9:55 AM, Filip Maj <fi...@adobe.com> wrote:
> 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?
>
With the current architecture, I believe it should upgrade all or none.
Dealing with multiple cordova app versions within the same project is
tricky and error prone.
Side note: This is one of the reasons why having apps self-contained in a
project vs separate can be an issue and why I wanted the cli tool to deal
with apps independently.
I agree that platform maintainers should start writing upgrade scripts
(from one version to the version immediately after) instead of upgrade
guides. The CLI would consume them.
I also agree that downgrades should not be available.
One tricky point as far as upgrades are concerned is plugins. How to
upgrade them with Cordova versions ? Will they work properly if/when
Cordova gets updated to a newer version ? Should the plugin spec be updated
to reflect multiple cordova versions support ?
Re: Cordova-CLI: Version handling
Posted by Brian LeRoux <b...@brian.io>.
Full circle! (Sorry I couldn't resist. This was the approach of a much
older iteration of the tools.)
Indicates to me this function should rest quietly in the backlog for a while.
On Fri, Jan 18, 2013 at 10:36 AM, Marcel Kinard <cm...@gmail.com> wrote:
> From the perspective of upgrading the shared project, if the user is asking
> to upgrade the project, and it is shared, then yes all their apps should
> see the upgrade. If they want only some of their apps to get upgraded, then
> they shouldn't be sharing.
>
> But it sounds like your point is really about the tools getting upgraded.
> Are the tools separate from Cordova and global to all the Cordova
> instances? If so, that definitely sounds like a slippery slope - would it
> be better to embed the tools in Cordova so that each Cordova instance has
> its own local tools? Then each instance is separate and self-contained and
> independent.
>
> -- Marcel Kinard
>
>> 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?
>>
Re: Cordova-CLI: Version handling
Posted by Marcel Kinard <cm...@gmail.com>.
>From the perspective of upgrading the shared project, if the user is asking
to upgrade the project, and it is shared, then yes all their apps should
see the upgrade. If they want only some of their apps to get upgraded, then
they shouldn't be sharing.
But it sounds like your point is really about the tools getting upgraded.
Are the tools separate from Cordova and global to all the Cordova
instances? If so, that definitely sounds like a slippery slope - would it
be better to embed the tools in Cordova so that each Cordova instance has
its own local tools? Then each instance is separate and self-contained and
independent.
-- Marcel Kinard
> 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?
>
Re: Cordova-CLI: Version handling
Posted by Brian LeRoux <b...@brian.io>.
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 <fi...@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" <cm...@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?
>
Re: Cordova-CLI: Version handling
Posted by Filip Maj <fi...@adobe.com>.
Cool, thanks for the feedback everyone! Sounds like downgrading won't be
supported for now.
On 1/18/13 9:07 AM, "Marcel Kinard" <cm...@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?
Re: Cordova-CLI: Version handling
Posted by Marcel Kinard <cm...@gmail.com>.
As a data point, this week I talked to a Cordova user who recently
published their app to the stores for iOS, Android, and Blackberry. I
asked him about his experience with Cordova, and one complaint was
around doing Cordova upgrades - he basically would start with a brand
new empty Cordova project in the IDE and then lay down his unchanged
application files, it's the opposite of laying down the new Cordova
files in the existing application project. I'm not saying it's not
possible, just that he had a bad experience with the upgrade
instructions in the doc and didn't trust an in-place upgrade. So if we
can get him to have a good experience with doing upgrades using the CLI,
that would be very cool.
On the plus side, he was very happy to basically single-source his app
across those three platforms.
On 1/17/2013 3:17 PM, Filip Maj wrote:
> On 1/17/13 11:57 AM, "Andrew Grieve"<ag...@chromium.org> wrote:
>> 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?
I like Andrew's idea of checksumming the files and displaying a
warning/confirmation that their mods are going to be lost. I worked on
building an appliance SDK, and we were constantly surprised at how many
customers were hacking the SDK to twiddle things they weren't supposed
to in order to get an unsupported customization. If they would have just
asked, we could have made it configurable, but apparently asking is the
last resort, kinda like guys reading the owner's manual. ;-)
>> I don't think we should put effort into downgrading. People should be
>> using
>> source-control for that.
I also suggest that downgrades not be supported in the tool. Keep it
simple, and move users forward. I worked on appliance firmware doing
downgrades, and it was a major pain. Run away! ;-) However, doing an
upgrade would be one of the main benefits.
>> 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.
-- Marcel Kinard
Re: Cordova-CLI: Version handling
Posted by Filip Maj <fi...@adobe.com>.
On 1/17/13 11:57 AM, "Andrew Grieve" <ag...@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..
>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?
>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.
>
>
>
>
>
>
>
>On Thu, Jan 17, 2013 at 2:15 PM, Filip Maj <fi...@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?
>>
>>
Re: Cordova-CLI: Version handling
Posted by Andrew Grieve <ag...@chromium.org>.
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?
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?
Fil, what are your thoughts around versioning the cordova-cli tool? 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.
On Thu, Jan 17, 2013 at 2:15 PM, Filip Maj <fi...@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?
>
>