The step of having to update the project reference would probably still been confusing / annoying. I've just enhanced the script so that it converts the file and also updates your project file.
The upgrade instructions will now be: 1. Drop in new CordovaLib 2. Drop in updated cordova.js 3. Run cordova_plist_to_config_xml . I think it's pretty reasonable to do a hard break if we provide a script to do the step for them. On Tue, Dec 4, 2012 at 5:31 PM, Braden Shepherdson <[email protected]>wrote: > 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 <[email protected]> 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. > >> > > > > >
