cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <>
Subject Re: Cordova upgrade scripts and 3.6.0 / whitelist
Date Fri, 22 Aug 2014 18:52:14 GMT
Documentation is definitely a way out of this. I'd like to avoid the
developer hassle that we introduced with File, when upgrading meant that
previously working behaviour suddenly stopped working, so I'm trying to
explore other alternatives first.

On Fri, Aug 22, 2014 at 2:24 PM, Michal Mocny <> wrote:

> Personally, I think we could just document the steps to manually update the
> config.xml's.
> We have no concept at all of CLI project upgrades.  If we change the
> default hooks/ format, or remove merges/ by default, you have to re-create
> the project to see those changes.  I think this is similar.  If new cordova
> projects have the new settings by default, the upgrade flow for many users
> could just be to "recreate with import", and we document how to upgrade
> in-place best we can.
> In a world of platforms-as-artefacts that we are trying to move towards, we
> won't need upgrades beyond uninstall & reinstall, so I don't think we
> should spend time on improving upgrade flows.  (I realize we aren't there
> yet, so we should do what we can for now).
> -Michal
> On Fri, Aug 22, 2014 at 2:06 PM, Ian Clelland <>
> wrote:
> > I'm trying to finish up the work on CB-7291 (The external launch
> whitelist
> > for Android) and I'm running into some conceptual issues with the upgrade
> > scripts that we have currently.
> >
> > The problems come from the fact that some upgrades should only be done
> > once, and that upgrading is done at a platform (rather than project)
> level,
> > but the whitelist is specified at the project level.
> >
> > I want to add the default whitelist to an application which is upgrading
> to
> > Cordova 3.6.0 (really just Android 3.6.0 now, in the new world of
> > independent releases). This needs to be done in the project-level
> > config.xml for CLI projects, and really should be done to the platform
> > config.xml for plugman projects. Also, if it has already been upgraded,
> > then don't do it again (we shouldn't unconditionally add the lines,
> > especially if the developer has explicitly removed them)
> >
> > Right now, you can only update a single platform at a time, so developers
> > will have to run "cordova platform upgrade android". That will delegate
> to
> > cordova-android's update script to do the actual work, which seems
> > correct (should cordova-lib have to know about all of the versions of
> each
> > platform in order to do its job?)
> >
> > I've modified the scripts now so that they know what version they are
> > upgrading *from*, so I can put in a condition like "if upgrading from
> > <3.6.0, then add the whitelist lines to config". The problem is that the
> > cordova-android scripts really *shouldn't* be depending on, or touching,
> > the top-level config.xml. I could put the logic in the cordova-lib
> scripts,
> > but it seems like the wrong place.
> >
> > I also don't really want to have the same logic duplicated -- once in
> > cordova-lib and again in the platform scripts, to do this twice.
> >
> > If anyone has any clear ideas on this, I'm open to them. If not, I'm
> going
> > to do what it takes to get this working today, so that we can actually
> > release 3.6.0
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message