Re: config.xml refactoring

[Brian LeRoux <b...@brian.io>]

Another use case is configuration meta data for native projects. Anyhow,
look fwd to the proposal.


On Wed, Aug 28, 2013 at 10:49 AM, Braden Shepherdson <br...@chromium.org>wrote:

> So we have several bugs[1][2][3] about fixing the handling of config.xml
> and of upgrading CLI projects. Upgrading platforms is hard because the user
> might have been modifying files in the platforms/foo directory, and we
> don't want to go overwriting them. Most of the time the file that's been
> changed is the platform's config.xml.
>
> So we (the Google team) are working on a proposal for rearranging how we
> handle config.xml files in order to make upgrades easier, and solving some
> of these other problems (splash screens) easier. Also to make the CLI
> tooling simpler, because currently the platform config.xml file is both the
> input and output of several processes (mainly adding and removing plugins,
> as well as cordova prepare).
>
> What we want to know, in writing this proposal is: what use-cases for the
> config.xml files are there? There seem to be two:
> 1. Not using CLI, just bin/create and maybe Plugman.
> 2. Using CLI, and needing to upgrade smoothly from the 3.0 world to 3.1
> with these changes to the files.
>
> Is there anything else we should be thinking about? If not, we'll have the
> proposal sent around tomorrow.
>
>
> Braden
>
> [1] https://issues.apache.org/jira/browse/CB-4624
> [2] https://issues.apache.org/jira/browse/CB-3216
> [3] https://issues.apache.org/jira/browse/CB-3571
>