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"<[email protected]> 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
