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 braden@google.com designates
 209.85.210.175 as permitted sender)
MIME-Version: 1.0
Sender: braden@google.com
In-Reply-To: <50BE7789.4090508@gmail.com>
References: 
 <CAE6O_-arNrZGCS__+pUxJzKoxatTqFCU2UM-Rqvt5opeTt7rPw@mail.gmail.com>
	<CCDA75BF.1235C%fil@adobe.com>
	<CAMk5LL=ViHp9kNqcGoU4cb4+CCttVbLKTdiZr_6U9cUqEcY0Mw@mail.gmail.com>
	<CANpVHHwk95jKsgYGMPr-5wh7FrKYp4HbYLk5Lu3d+yukaP3EEQ@mail.gmail.com>
	<CAMk5LLk11zjx2tOesprV-enFTWKx7K9-A_ORCAXDe5ZV9VidBg@mail.gmail.com>
	<CABiQX1UrO4W9Lf+tydUEXe-bvViT-1VGN9eKcHSwJ=jrw2_QLA@mail.gmail.com>
	<CAE6O_-ZH+w9Jk0ZZ5jPcUFe=mL9U_EEZerPSPyDw3nfxx_AybQ@mail.gmail.com>
	<CAMk5LLkTSEEc6s8_Jz55B1A+-vSjC2-85oc1R7imzm7K+-J_Sg@mail.gmail.com>
	<50BE7789.4090508@gmail.com>
Date: Tue, 4 Dec 2012 17:31:21 -0500
Message-ID: 
 <CAMk5LLmeQfTvQg6rfH+z8nOiC2s4LvVwQUG=+smzcKhT3S=2sg@mail.gmail.com>
Subject: Re: [iOS] Cordova.plist to config.xml - deprecation
From: Braden Shepherdson <braden@chromium.org>
To: dev@cordova.apache.org
Content-Type: multipart/alternative; boundary=14dae9341235e3642a04d00e6c8b

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

The undesirable behavior with that approach is that the user can be
wondering why their changes to the old file are not being picked up.
They'll have to migrate sometime, and if we've provided the tool and warn
them in release notes and elsewhere, then I think this approach is
reasonable.

Braden


On Tue, Dec 4, 2012 at 5:22 PM, Marcel Kinard <cmarcelk@gmail.com> wrote:

> On 12/3/2012 12:02 PM, Braden Shepherdson wrote:
>
>> Instant migration, with the conversion script. Deprecation policy is good
>> in general, but having both and wondering why your changes to the old one
>> are not propagating is a problem. Therefore I'm for the clean break.
>>
>
> Will the conversion script run automatically if the customer has a plist
> file and no xml file on 2.3? If not, then customers will be broken without
> explicit action on their part (even though the action is small). That's not
> deprecation.
>
> Is there something undesirable with the following? This sounds more
> graceful from a customer perspective.
>
>
> On 11/27/2012 4:40 PM, Shazron wrote:
>
>> Yup -- I think it can work like this - firstly iOS would try to use
>> config.xml, not found? use Cordova.plist. If it uses Cordova.plist, we
>> print the deprecation message.
>>
>
>

--14dae9341235e3642a04d00e6c8b--