would different versions will work ok?
On Sat, Sep 29, 2012 at 2:33 AM, Andrew Grieve <[email protected]> wrote: > Another options I've now thought of, and I think I like this one the best > :). > > Instead of copying the entire CordovaLib directory into each project, just > copy the CordovaLib.xcodeproj file. This will allow each project to be open > at the same time, since they will technically reference different projects, > but they will all reference the same source files. To upgrade cordova > versions, our update_cordova_subproject.sh script can clobber the > .xcodeproj proj file with the newer one. > > > On Fri, Sep 28, 2012 at 6:42 AM, Brian LeRoux <[email protected]> wrote: > >> thinking a bundled upgrade cli command in all the projects is a good >> idea... something that automates whatever we document in the upgrade >> guide >> >> >> >> On Thu, Sep 27, 2012 at 6:58 PM, Jesse <[email protected]> wrote: >> > Mis-understood some of the finer points, thanks for the clarification >> > and patience all. >> > >> > I agree that option 2 makes the most sense. >> > >> > On Thu, Sep 27, 2012 at 9:52 AM, Mike Reinstein >> > <[email protected]> wrote: >> >> an upgrade script would be really helpful as well. >> >> >> >> -Mike >> >> >> >> On Thu, Sep 27, 2012 at 12:44 PM, Piotr Walczyszyn < >> >> [email protected]> wrote: >> >> >> >>> As I suggested in the pull request comments, this would really make >> >>> sense to update bin/create script either by enhancing it with >> >>> additional argument to embed the CordovaLib with newly created >> >>> projects or even make this behavior a default one. >> >>> >> >>> p. >> >>> >> >>> 2012/9/27 Andrew Grieve <[email protected]>: >> >>> > Suppose you have 5 projects that depend on 2.1, and 3 that depend on >> 2.0. >> >>> > >> >>> > One big difference between the two options is that for the 2nd >> option, >> >>> > you'd have 8 copies of Cordova, whereas for the first option you'd >> have >> >>> > only two. >> >>> > >> >>> > I think getting the correct workflow set up with Xcode workspaces >> will be >> >>> > quite cumbersome though, and not something that will be easy for us >> to do >> >>> > with tooling. We'd pretty much have to rely on documentation to tell >> >>> people >> >>> > how to drag multiple projects into their own workspace. >> >>> > >> >>> > I think maybe another key point is that CordovaLib is really small, >> and >> >>> > will get even smaller if/when we remove the core plugins from it. In >> this >> >>> > model, the majority of the code will be pluginstalled into users' >> >>> projects >> >>> > anyways, so it won't be a bit deal to have a bunch of copies of >> >>> CordovaLib >> >>> > around. >> >>> > >> >>> > The model that pwalczyszyn is using is to copy the CordovaLib >> directory >> >>> > into each project's directory, similar to how we have a "cordova" >> >>> directory >> >>> > that we copy into it. Taken from his pull requests comments: >> >>> > >> >>> > MyProject >> >>> >> -- cordova >> >>> >> -- MyProject >> >>> >> ---- CordovaLib >> >>> >> ------ CordovaLib.xcodeproj >> >>> >> ---- Plugins >> >>> >> ---- Resources >> >>> >> ---- .... >> >>> >> -- MyProject.xcodeproj >> >>> >> -- www >> >>> > >> >>> > >> >>> > Having CordovaLib a sibling of Plugins does make sense in this model >> I >> >>> > think. Either that, or have it up one level. >> >>> > >> >>> > >> >>> > To implement this, we'll need to change our bin/create script to >> copy in >> >>> > the CordovaLib directory. Not too hard. >> >>> > >> >>> > For upgrades, how will we address this though? Just add documentation >> >>> > telling users to delete the old directory and copy over the new one? >> The >> >>> > steps would be: >> >>> > cp -r path/to/new/cordova/CordovaLib MyProject >> >>> > path/to/new/cordova/bin/update_cordova_subproject MyProject >> >>> > MyProject/CordovaLib >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > On Thu, Sep 27, 2012 at 10:16 AM, Dave Johnson < >> [email protected] >> >>> >wrote: >> >>> > >> >>> >> +1 >> >>> >> >> >>> >> On Thursday, September 27, 2012, Mike Reinstein wrote: >> >>> >> >> >>> >> > Agree on all points with Brian. >> >>> >> > >> >>> >> > On Thu, Sep 27, 2012 at 6:34 AM, Brian LeRoux <[email protected] >> >>> <javascript:;>> >> >>> >> > wrote: >> >>> >> > >> >>> >> > > > Global dependancies? It's a library, why would you not be >> >>> dependent >> >>> >> on >> >>> >> > > it? >> >>> >> > > > >> >>> >> > > >> >>> >> > > We're talking about global deps vs local deps. Not whether or >> not >> >>> >> you'll >> >>> >> > > have a dependency! >> >>> >> > > >> >>> >> > > >> >>> >> > > > Standardize on the apis and not the files. >> >>> >> > > > >> >>> >> > > >> >>> >> > > Uh, ok sure, not sure I understand? >> >>> >> > > >> >>> >> > > It only takes a few weeks of ruby (and/or python) dev to see >> where >> >>> >> global >> >>> >> > > packages become ambushes for epic fail. Node learned from this >> and >> >>> >> > > explicitly created lexically scoped packages. Typically when you >> >>> ship >> >>> >> > > projects you want to have the dependencies bundled to minimize >> >>> issues. >> >>> >> > > >> >>> >> > > See http://en.wikipedia.org/wiki/Dependency_hell >> >>> >> > > >> >>> >> > > >> >>> >> > > Not to mention the extra complexity of #2, and multiple out of >> sync >> >>> >> > > > project issues. >> >>> >> > > > >> >>> >> > > >> >>> >> > > I do not see where this creates complexity. It reduces it. I >> have a >> >>> >> > project >> >>> >> > > that I want up-do-date. It has a dependency on 2.1.0. I have >> another >> >>> >> > > project I do not want to update running 2.0.0: no problem. If I >> >>> have a >> >>> >> > > global dependency: problem! >> >>> >> > > >> >>> >> > > The other issue here is the requirement of having your library >> >>> >> > > a separate concern for the end user project. When I want to >> build a >> >>> >> > project >> >>> >> > > from another repo it requires me to install the correct version >> of >> >>> the >> >>> >> > > dependency. With option 2 the library is a part of the project >> and >> >>> no >> >>> >> > > installer step is required. Again: reduced complexity. >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > > I originally moved the codebase to a library and created the >> >>> template >> >>> >> > > > over 2 years ago, so I may be blind to the benefits of #2, >> but to >> >>> me >> >>> >> > > > this makes our library become a boilerplate... am I wrong? >> >>> >> > > > >> >>> >> > > >> >>> >> > > Do not see how this is related either. >> >>> >> > > >> >>> >> > >> >>> >> >> >>> >> > >> > >> > >> > -- >> > @purplecabbage >> > risingj.com >>
