The versions of cordova-ios, etc are tied to your version of CLI, so this may actually be an argument to keep them with cordova-ios and not in the project template. I think so long as we add a bin/upgrade_project project_path that it doesn't really matter. We need to update the native bits anyways, and such a script would be nice.
On Mon, Apr 29, 2013 at 7:09 PM, Brian LeRoux <b...@brian.io> wrote: > Main reason was to vendor in the scripts with the version of the src > they would operate on. > > On Mon, Apr 29, 2013 at 11:31 AM, Shazron <shaz...@gmail.com> wrote: > > *over-write > > (oops on the oop) > > > > > > On Mon, Apr 29, 2013 at 11:15 AM, Shazron <shaz...@gmail.com> wrote: > > > >> I think the main purpose of the scripts being in the project is that > they > >> can exist outside of having the repo source download around, afaik. > >> The script upgrades which I've been documenting have been a straight > copy > >> and paste of the whole 'cordova' folder. I suppose we could have a: > >> > >> bin/cli-upgrade project_path > >> > >> ...which would just do a copy and override. If one had their own > >> customizations in there I suppose they can merge the changes if they had > >> source control (we could warn them before overwriting I suppose). > >> > >> > >> On Mon, Apr 29, 2013 at 8:19 AM, Andrew Grieve <agri...@chromium.org > >wrote: > >> > >>> Shaz took care of a lot of these for iOS (awesome!). > >>> > >>> Right now they live in the project template (along with the older > >>> scripts). > >>> > >>> There is a current issue about the fact that these scripts are not > updated > >>> when upgrading your version of Cordova ( > >>> https://issues.apache.org/jira/browse/CB-2448) > >>> > >>> Since the main consumer of these APIs will be CLI, how about we take > them > >>> out of the project template, and instead have them live within the > device > >>> repos. E.g. for iOS, have them live as a sibling of CordovaLib, and > have > >>> CLI know how to invoke them. > >>> > >> > >> >
