Re: [iOS] Cordova.plist to config.xml - deprecation

[Shazron <sh...@gmail.com>]

I think having the conversion script makes sense (and you've already
implemented it, thanks Andrew). Supporting both can cause confusion.

So.... what is the consensus if any here.


On Thu, Nov 29, 2012 at 10:40 AM, Andrew Grieve <ag...@chromium.org>wrote:

> Copying from the JIRA issue to this thread:
>
> I think supporting both was one of the things that upset users when Android
> > made the switch (at least, it upset me). What happened was that I ended
> up
> > having both files present, and the code was silently using one and not
> the
> > other, and I couldn't figure out why my whitelist changes were not being
> > picked up.
>
>
>
> >
> > I think a conversion script was also suggested. I think it would be best
> > to just fail loudly if config.xml is missing with a message saying "run
> > this script: cordova/bin/plist2xml.py path/to/cordova.plist
>
>
>
>
>
>
>
>
> On Thu, Nov 29, 2012 at 1:26 PM, Braden Shepherdson <braden@chromium.org
> >wrote:
>
> > Oh, sweet. I'm glad I went to lunch instead of working on it further :P
> >
> > Braden
> >
> >
> > On Thu, Nov 29, 2012 at 12:47 PM, Anis KADRI <an...@gmail.com>
> wrote:
> >
> > > I've already started working on pluginstall…which btw is now called
> > > plugman<http://github.com/imhotep/plugman>as it has diverged
> > > significantly from the original tool. I am expecting to
> > > commit the code sometime today.
> > >
> > >
> > > On Thu, Nov 29, 2012 at 8:38 AM, Braden Shepherdson <
> braden@chromium.org
> > > >wrote:
> > >
> > > > The code I checked in, which is now tagged, is expecting config.xml
> > only.
> > > > It wouldn't be terribly hard to support plists too, but I agree that
> a
> > > > clean change is less confusing.
> > > >
> > > > I think a conversion script is overkill, it only takes about three to
> > > > convert one to the other (30 seconds if you vim macros like a boss)
> and
> > > > plenty of people will be able to grab the example config.xml and
> tweak
> > > one
> > > > or two settings rather than converting their whole thing.
> > > >
> > > > The current state of error messages is less than ideal. Currently if
> > you
> > > > try to build but have no config.xml, you just get an Xcode error
> > message
> > > > about the missing file :( I'm not sure how we can improve that. Our
> > users
> > > > are used to looking at our release notes, featuring this prominently
> > and
> > > > pointing to a guide to converting should sort things out.
> > > >
> > > > I'm working on getting pluginstall to handle it properly. Are there
> > more
> > > > docs that need updating?
> > > >
> > > > Braden
> > > >
> > >
> >
>

Re: [iOS] Cordova.plist to config.xml - deprecation

[Andrew Grieve <ag...@chromium.org>]

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

Re: [iOS] Cordova.plist to config.xml - deprecation

[Braden Shepherdson <br...@chromium.org>]

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 <cm...@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.
>>
>
>

Re: [iOS] Cordova.plist to config.xml - deprecation

[Marcel Kinard <cm...@gmail.com>]

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.

Re: [iOS] Cordova.plist to config.xml - deprecation

[Braden Shepherdson <br...@chromium.org>]

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.

Braden


On Fri, Nov 30, 2012 at 7:13 PM, Shazron <sh...@gmail.com> wrote:

> I think having the conversion script makes sense (and you've already
> implemented it, thanks Andrew). Supporting both can cause confusion.
>
> So.... what is the consensus if any here.
>
>
> On Thu, Nov 29, 2012 at 10:40 AM, Andrew Grieve <agrieve@chromium.org
> >wrote:
>
> > Copying from the JIRA issue to this thread:
> >
> > I think supporting both was one of the things that upset users when
> Android
> > > made the switch (at least, it upset me). What happened was that I ended
> > up
> > > having both files present, and the code was silently using one and not
> > the
> > > other, and I couldn't figure out why my whitelist changes were not
> being
> > > picked up.
> >
> >
> >
> > >
> > > I think a conversion script was also suggested. I think it would be
> best
> > > to just fail loudly if config.xml is missing with a message saying "run
> > > this script: cordova/bin/plist2xml.py path/to/cordova.plist
> >
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Nov 29, 2012 at 1:26 PM, Braden Shepherdson <braden@chromium.org
> > >wrote:
> >
> > > Oh, sweet. I'm glad I went to lunch instead of working on it further :P
> > >
> > > Braden
> > >
> > >
> > > On Thu, Nov 29, 2012 at 12:47 PM, Anis KADRI <an...@gmail.com>
> > wrote:
> > >
> > > > I've already started working on pluginstall…which btw is now called
> > > > plugman<http://github.com/imhotep/plugman>as it has diverged
> > > > significantly from the original tool. I am expecting to
> > > > commit the code sometime today.
> > > >
> > > >
> > > > On Thu, Nov 29, 2012 at 8:38 AM, Braden Shepherdson <
> > braden@chromium.org
> > > > >wrote:
> > > >
> > > > > The code I checked in, which is now tagged, is expecting config.xml
> > > only.
> > > > > It wouldn't be terribly hard to support plists too, but I agree
> that
> > a
> > > > > clean change is less confusing.
> > > > >
> > > > > I think a conversion script is overkill, it only takes about three
> to
> > > > > convert one to the other (30 seconds if you vim macros like a boss)
> > and
> > > > > plenty of people will be able to grab the example config.xml and
> > tweak
> > > > one
> > > > > or two settings rather than converting their whole thing.
> > > > >
> > > > > The current state of error messages is less than ideal. Currently
> if
> > > you
> > > > > try to build but have no config.xml, you just get an Xcode error
> > > message
> > > > > about the missing file :( I'm not sure how we can improve that. Our
> > > users
> > > > > are used to looking at our release notes, featuring this
> prominently
> > > and
> > > > > pointing to a guide to converting should sort things out.
> > > > >
> > > > > I'm working on getting pluginstall to handle it properly. Are there
> > > more
> > > > > docs that need updating?
> > > > >
> > > > > Braden
> > > > >
> > > >
> > >
> >
>