Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of mmocny@google.com designates
 209.85.219.46 as permitted sender)
MIME-Version: 1.0
Sender: mmocny@google.com
In-Reply-To: 
 <CAMk5LLmCoVBusKMqOJBfxowGpBLu2FnNU-rwjmDVQ8_1OphkDw@mail.gmail.com>
References: 
 <CAMk5LLmCoVBusKMqOJBfxowGpBLu2FnNU-rwjmDVQ8_1OphkDw@mail.gmail.com>
From: Michal Mocny <mmocny@chromium.org>
Date: Wed, 28 Aug 2013 14:15:21 -0400
Message-ID: 
 <CAEeF2Tcqbi7ac1e+on3i59szZ1fuA6uUM8PJcGgXNkB6emVeTg@mail.gmail.com>
Subject: Re: config.xml refactoring
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=e89a8fb1fde62c026d04e505faf3

--e89a8fb1fde62c026d04e505faf3
Content-Type: text/plain; charset=ISO-8859-1

FYI: This was a quick whiteboard discussion this morning that started with
"why do I need to modify the platform config just to update my
application's name", and sorta spiraled into an interesting idea to
potentially solve this problem once and for all.

Trying to make sure we haven't missed anything before putting the effort
into formulating it into an email.


On Wed, Aug 28, 2013 at 1:49 PM, Braden Shepherdson <braden@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
>

--e89a8fb1fde62c026d04e505faf3--