cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Cordova upgrade scripts and 3.6.0 / whitelist
Date Fri, 22 Aug 2014 18:06:50 GMT
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

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