Cordova upgrade scripts and 3.6.0 / whitelist

[Ian Clelland <ic...@chromium.org>]

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

Re: Cordova upgrade scripts and 3.6.0 / whitelist

[Ian Clelland <ic...@chromium.org>]

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 <mm...@chromium.org> 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 <ic...@chromium.org>
> 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
> >
>

Re: Cordova upgrade scripts and 3.6.0 / whitelist

[Michal Mocny <mm...@chromium.org>]

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 <ic...@chromium.org>
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
>