So for the sake of moving the RC release along, Michal/Braden/Andrew are you guys cool if we:
A) revert to www/ as root folder B) proceed with 2.8.0rc1 tagging C) continue with this discussion to try to get to a resolution. Worst-case we call a vote next week? On 5/23/13 10:56 AM, "Michal Mocny" <mmo...@chromium.org> wrote: >Fil, that sounds extremely sensible. > > >On Thu, May 23, 2013 at 12:32 PM, Filip Maj <f...@adobe.com> wrote: > >> https://npmjs.org/package/cordova >> >> >> While CLI is not a documented flow, it is deployed and has > 1000 >> downloads per month. >> >> That's my only concern: not fucking those people over. >> >> I'm in favor of that structure I just don't want it to change without >> warning in this next release. Ideally set up deprecation messages, be >> noisy about the change, and sure, possibly supporting a transitioning >> automatically in our tooling, and then land it in full and remove >> deprecation messages about it in 3.0. >> >> On 5/23/13 9:27 AM, "Michal Mocny" <mmo...@chromium.org> wrote: >> >> >Clarification of typing mistake, below.. >> > >> >Also, curious why this breaks things in the first place? I thought >>this >> >is >> >the first time we are releasing these tools? The current create script >> >workflow is totally different, and I know there is a npm package for >> >cordova cli already, but that was never a promoted flow (matter of >>fact, >> >why was it released? Are we supporting current users of that, is that >>it?) >> > >> >-Michal >> > >> >On Thu, May 23, 2013 at 12:22 PM, Michal Mocny <mmo...@chromium.org> >> >wrote: >> > >> >> Brian, >> >> I do not really understand your previous point, but I'll take a stab. >> >> >> >> First some clarification: I think there are two logical "roots", (1) >> >>the >> >> root of your web app (holds merges/ and www/ and maybe more), and (2) >> >>the >> >> root of your cordova workspace (holds platforms/ plugins/ and maybe >> >>more). >> >> >> >> With the app/ folder, (1) is a subdirectory (2). With the current >> >> situation, they overlap inside the same folder. >> >> >> >> I think it should be a goal to version control, share, and perhaps >> >>bundle >> >> auxiliary resources with app/'s. >> >> I think it should also be a goal to not limit the future structure of >> >>the >> >> cordova workspace (ie, build artifacts). >> >> >> >> The current situation makes these goals harder. >> >> >> >> As one data point, our team here has a workflow where we share >>several >> >> apps (containing only the contents(2)), and we share the common >>plugins >> >>we >> >> work on. >> >> The contents of (1) are never committed, shared, etc, and are just >> >> recreated on a regular basis as cordova versions change and as we >>test >> >>for >> >> different platforms. Sidenote: yes, I have multiple different >>cordova >> >> workspaces pointing to one common app to test with different >>versions. >> >> This is a bit of a cordova-developer necessity, but it would be >> >> interesting if external devs could trial out new cordova releases on >>the >> >> side, trivially.. >> >> >> >Sigh, of course I got the numbers reversed here.. my bad. Of course I >> >mean >> >we only commit (1). >> > >> > >> >> >> >> >> >> So, like you Brian, we are just trying to get all the >> >>requirements/wishes >> >> on the table so we can make a conscious decision here. It looks like >> >>you >> >> are not seeing sufficient motivation for making the change, and we >>are >> >>not >> >> seeing any reason to not make it. >> >> >> >> Another observation: the transition path even easier than we have >> >>outlined >> >> above. >> >> >> >> If your existing project is: >> >> - app_name/ >> >> - platforms/ >> >> - plugins/ >> >> - www/ >> >> - merges/ >> >> >> >> All you need to do is rm -rf platforms/ plugins/ www/config.xml -- >>which >> >> you need to do anyway to upgrade to 3.0 -- create a new config.xml at >> >>the >> >> root and you now have a shareable app, and you can create as many >> >>cordova >> >> different workspaces using it as you want. >> >> >> >> -Michal >> >> >> >> >> >> On Thu, May 23, 2013 at 11:47 AM, Brian LeRoux <b...@brian.io> wrote: >> >> >> >>> Not buying that either. The `./app` directory lives in the root so >> >>> everything will have to change when we hit the reality you describe >> >>> where `./app` IS the root. >> >>> >> >>> What you are really saying this is a transition step until such time >> >>> as `./app` becomes top level and things return to the same as they >>are >> >>> today but we do not require native bits to be revisioned. >>Essentially >> >>> this is an aesthetic forcing function to get back to the original >> >>> structure. =P >> >>> >> >>> This is a very complicated way to achieve the goal of native bits >> >>> being build artifacts. A goal I share, many do, and I think we can >> >>> achieve it by NOT breaking things today. >> >>> >> >>> >> >>> On Thu, May 23, 2013 at 8:21 AM, Braden Shepherdson >> >>><bra...@chromium.org> >> >>> wrote: >> >>> > cd app >> >>> > git init >> >>> > >> >>> > Now my app directory - everything that makes this app mine and >>isn't >> >>> just a >> >>> > cordova-cli artifact - is version controlled. I can easily check >>out >> >>>a >> >>> new >> >>> > copy with a cordova create ...; rm -rf app; git clone https:// >> >>> .../myrepo.git >> >>> > app >> >>> > >> >>> > Once we have app-level dependencies (which is planned >>regardless), I >> >>>can >> >>> > add cordova fetch-deps or whatever we decide the command should >>be, >> >>>and >> >>> now >> >>> > my app is fully set up. No need to juggle .gitignore or anything >> >>>else. >> >>> It's >> >>> > hardly a killer feature, but I think it is an improvement. >> >>> > >> >>> > Michal asked what change we would regret more a year from now. I >> >>>think >> >>> this >> >>> > style makes the separation of CLI artifacts and my app more clear, >> >>>and >> >>> if >> >>> > we add more pieces to either it won't require changing people's >> >>> .gitignore >> >>> > files or knowing about the architecture. >> >>> > >> >>> > Braden >> >>> > >> >>> > >> >>> > On Thu, May 23, 2013 at 11:15 AM, Brian LeRoux <b...@brian.io> wrote: >> >>> > >> >>> >> I want to be very clear that my tone here is emotionless! I'm >> >>>totally >> >>> >> indifferent. >> >>> >> >> >>> >> Now, please explain: how is a new directory make version control >> >>> >> easier? I don't buy it. >> >>> >> >> >>> >> >> >>> >> On Thu, May 23, 2013 at 8:02 AM, Braden Shepherdson < >> >>> bra...@chromium.org> >> >>> >> wrote: >> >>> >> > The change is not purely aesthetic; it means that the "my app" >> >>> portions >> >>> >> of >> >>> >> > the structure are now contained in a single directory, and >>easier >> >>>to >> >>> >> > version control. >> >>> >> > >> >>> >> > This change gets more expensive every day. If we're ever going >>to >> >>>do >> >>> it, >> >>> >> it >> >>> >> > should be done now, I believe. >> >>> >> > >> >>> >> > It seems like the (not universally supported) consensus from >>the >> >>> first >> >>> >> pass >> >>> >> > at this thread was to keep the app/ dir but have automatic >> >>>detection >> >>> and >> >>> >> > ask-then-automatic conversion. >> >>> >> > >> >>> >> > If that approach is still acceptable, I will implement that >> >>>support >> >>> today >> >>> >> > before we tag CLI for 2.8. >> >>> >> > >> >>> >> > Braden >> >>> >> > >> >>> >> > >> >>> >> > On Thu, May 23, 2013 at 12:30 AM, Michal Mocny >> >>><mmo...@chromium.org> >> >>> >> wrote: >> >>> >> > >> >>> >> >> Fil, good summary, thanks for that. I also agree with your >> >>> proposal. >> >>> >> >> Would it be possible to just support both options starting >>now, >> >>>and >> >>> >> >> "deprecate" www/ at the top level in 3.0? >> >>> >> >> >> >>> >> >> Brian, this isn't just aesthetics, but its true that either >> >>>option >> >>> can, >> >>> >> >> with varying difficulty, be made to work for all use cases. >> >>> >> >> >> >>> >> >> Migration path is trivial but will be paid by all users, >>still, >> >>> >> workflows >> >>> >> >> will change completely with 3.0 anyway, this being the least >>of >> >>>the >> >>> >> >> changes. Which decision is more likely to be regretted a year >> >>>from >> >>> now? >> >>> >> >> >> >>> >> >> -Michal >> >>> >> >> >> >>> >> >> >> >>> >> >> On Wed, May 22, 2013 at 10:11 PM, Andrew Grieve < >> >>> agri...@chromium.org >> >>> >> >> >wrote: >> >>> >> >> >> >>> >> >> > I don't really think this directory change is a big deal. We >> >>>break >> >>> >> things >> >>> >> >> > in almost every release (e.g. loading pages of http), yet >>we're >> >>> >> having so >> >>> >> >> > much debate over alpha tool. >> >>> >> >> > >> >>> >> >> > The migration path is: mkdir app && git mv www merges app && >> >>>git >> >>> mv >> >>> >> >> > app/www/config.xml app >> >>> >> >> > >> >>> >> >> > I think the least amount of work here is to just >>console.log an >> >>> error >> >>> >> >> > message with this command if the app/ directory is not >>found. >> >>> >> >> > >> >>> >> >> > >> >>> >> >> > On Wed, May 22, 2013 at 9:28 PM, Tommy-Carlos Williams >> >>> >> >> > <to...@devgeeks.org>wrote: >> >>> >> >> > >> >>> >> >> > > Is it bad that I both agree vehemently with Brian's >>calling >> >>>it >> >>> not >> >>> >> >> > > beneficial enough to justify, but also really really like >>the >> >>> >> proposed >> >>> >> >> > > structure better that the current one? hehe. >> >>> >> >> > > >> >>> >> >> > > *soŠ conflicted...* >> >>> >> >> > > >> >>> >> >> > > - tommy >> >>> >> >> > > >> >>> >> >> > > On 23/05/2013, at 7:35 AM, Brian LeRoux <b...@brian.io> >>wrote: >> >>> >> >> > > >> >>> >> >> > > > There are two paths. I argue there is no functional >>benefit >> >>> and >> >>> >> that >> >>> >> >> > > > this change is purely aesthetic. Aesthetics are >>important >> >>>but >> >>> I'd >> >>> >> >> > > > argue folder structure is the last part of the developer >> >>> >> aesthetics >> >>> >> >> we >> >>> >> >> > > > should worry about and especially not beneficial enough >>to >> >>> >> justify a >> >>> >> >> > > > breaking change. >> >>> >> >> > > > >> >>> >> >> > > > Today: >> >>> >> >> > > > >> >>> >> >> > > > ./ >> >>> >> >> > > > |- merges/ >> >>> >> >> > > > |- platforms/ >> >>> >> >> > > > |- plugins/ >> >>> >> >> > > > '- www/ >> >>> >> >> > > > |- index.html >> >>> >> >> > > > '- config.xml >> >>> >> >> > > > >> >>> >> >> > > > Proposed: >> >>> >> >> > > > >> >>> >> >> > > > ./ >> >>> >> >> > > > |- platforms/ >> >>> >> >> > > > |- plugins/ >> >>> >> >> > > > '- app/ >> >>> >> >> > > > |- merges/ >> >>> >> >> > > > |- www/ >> >>> >> >> > > > | '- index.html >> >>> >> >> > > > '- config.xml >> >>> >> >> > > > >> >>> >> >> > > > >> >>> >> >> > > > >> >>> >> >> > > > >> >>> >> >> > > > On Wed, May 22, 2013 at 1:47 PM, Filip Maj >><f...@adobe.com> >> >>> wrote: >> >>> >> >> > > >> I'm reviving this discussion re: additional app/ >>folder in >> >>> the >> >>> >> >> > > >> cli-generated project structure. >> >>> >> >> > > >> >> >>> >> >> > > >> To recap, there were two main discussions: >> >>> >> >> > > >> >> >>> >> >> > > >> A) >> >>> >> >> > > >> >> >>> >> >> > > >> >>> >> >> > >> >>> >> >> >> >>> >> >> >>> >> >>> >> http://apache.markmail.org/thread/syo24cwvhpkxqfdm#query:+page:1+mid:j76 >> >>>xli >> >>> >> >> > > >> hsfjmvwtoi+state:results >> >>> >> >> > > >> B) >> >>> >> http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html >> >>> >> >> > > >> >> >>> >> >> > > >> Arguments for moving to app/: >> >>> >> >> > > >> >> >>> >> >> > > >> - easier to version control relevant / >>non-build-artifact >> >>>app >> >>> >> bits >> >>> >> >> > > >> - aesthetics >> >>> >> >> > > >> >> >>> >> >> > > >> Arguments against it: >> >>> >> >> > > >> >> >>> >> >> > > >> - we break shit for users >> >>> >> >> > > >> - config.xml location and PhoneGap Build compatibility >> >>>(but I >> >>> >> don't >> >>> >> >> > see >> >>> >> >> > > >> this as a valid argument against. This is an easy >>problem >> >>>to >> >>> >> solve >> >>> >> >> for >> >>> >> >> > > us >> >>> >> >> > > >> Adobe folk and the tooling can handle the trivial >>steps of >> >>> going >> >>> >> up >> >>> >> >> > one >> >>> >> >> > > >> directory to grab the right file before interfacing >>with >> >>> Build) >> >>> >> >> > > >> >> >>> >> >> > > >> Also worth noting: people we're not against it for >> >>> architectural >> >>> >> >> > > reasons, >> >>> >> >> > > >> in fact, most people were favorable for the change to >> >>>app/. >> >>> >> >> > > >> >> >>> >> >> > > >> So, with plugman stabilizing and my focus moving to cli >> >>> work, I >> >>> >> >> feel I >> >>> >> >> > > >> have a good grasp of both projects and the direction >>they >> >>>are >> >>> >> going, >> >>> >> >> > > here >> >>> >> >> > > >> is my suggestion on how to move forward with this: >> >>> >> >> > > >> >> >>> >> >> > > >> 1. cordova-cli's master branch, which will soon merge >> >>>future >> >>> work >> >>> >> >> in, >> >>> >> >> > > will >> >>> >> >> > > >> revert to the old /www-based structure, then >> >>> >> >> > > >> 2. In 3.0 we make the change, where landing such a >> >>>breaking >> >>> >> change >> >>> >> >> is >> >>> >> >> > > >> easier and we'll have a bunch of press/noise about the >> >>> release >> >>> >> out >> >>> >> >> > there >> >>> >> >> > > >> too so communicating this change would be easier. >> >>> >> >> > > >> >> >>> >> >> > > >> If there are any other arguments for/against the app/ >> >>>based >> >>> >> >> structure, >> >>> >> >> > > now >> >>> >> >> > > >> is the time to bring it up. We can give this some more >> >>>time >> >>> to >> >>> >> bake, >> >>> >> >> > but >> >>> >> >> > > >> after 2.8 is released, I'd like to call a vote on >>whether >> >>>we >> >>> >> should >> >>> >> >> > move >> >>> >> >> > > >> to this structure or not in 3.0. >> >>> >> >> > > >> >> >>> >> >> > > >> On 4/16/13 8:31 AM, "Michal Mocny" >><mmo...@chromium.org> >> >>> wrote: >> >>> >> >> > > >> >> >>> >> >> > > >>> I should also add. I appreciate that this is a >>change, >> >>>and >> >>> >> every >> >>> >> >> > > change >> >>> >> >> > > >>> has some learning overhead and we shouldn't stuff >> >>>everything >> >>> >> >> possible >> >>> >> >> > > in >> >>> >> >> > > >>> all the time. >> >>> >> >> > > >>> >> >>> >> >> > > >>> However, I think 3.0 and cli are a big change, and we >> >>> should do >> >>> >> the >> >>> >> >> > big >> >>> >> >> > > >>> re-org all at once, so lets decide this now in a way >>we >> >>>wont >> >>> >> >> regret. >> >>> >> >> > > >>> Thats >> >>> >> >> > > >>> why we are being picky, I guess. I like knowing that >>the >> >>> root >> >>> >> of >> >>> >> >> the >> >>> >> >> > > >>> project has cordova-only artifacts and your app-repo >>is >> >>> just a >> >>> >> >> > > >>> subdirectory >> >>> >> >> > > >>> somewhere. Then, the exact location and exact >>contents >> >>>are >> >>> way >> >>> >> >> more >> >>> >> >> > > >>> flexible. >> >>> >> >> > > >>> >> >>> >> >> > > >>> -Michal >> >>> >> >> > > >>> >> >>> >> >> > > >>> >> >>> >> >> > > >>> On Tue, Apr 16, 2013 at 11:18 AM, Michal Mocny < >> >>> >> >> mmo...@chromium.org> >> >>> >> >> > > >>> wrote: >> >>> >> >> > > >>> >> >>> >> >> > > >>>> Okay, we've got options, so lets try to distill the >> >>> details. >> >>> >> >> > > >>>> >> >>> >> >> > > >>>> First, some of the other (perceived) benefits of an >>app >> >>> folder >> >>> >> >> are: >> >>> >> >> > > >>>> * we do a raw cp -r of the www/ folder, and so that >> >>>should >> >>> have >> >>> >> >> only >> >>> >> >> > > >>>> platform agnostic and "necessary" files. >> >>> >> >> > > >>>> * merges folder was removed from www/ because it did >>not >> >>> meet >> >>> >> >> above >> >>> >> >> > > >>>> criteria, and config.xml is another candidate >> >>> >> >> > > >>>> * there also potentially exist docs/ (useful for >>shared >> >>> apps, >> >>> >> like >> >>> >> >> > > >>>> mobile-spec), platform specific resource files >>(icons, >> >>> splash >> >>> >> >> > screen), >> >>> >> >> > > >>>> etc >> >>> >> >> > > >>>> * a git repository is already basically mirroring the >> >>> concept >> >>> >> of >> >>> >> >> the >> >>> >> >> > > >>>> "app >> >>> >> >> > > >>>> folder" >> >>> >> >> > > >>>> >> >>> >> >> > > >>>> So, I've come up with the following potential >>workflows >> >>>for >> >>> >> >> starting >> >>> >> >> > > >>>> with >> >>> >> >> > > >>>> an existing app: >> >>> >> >> > > >>>> >> >>> >> >> > > >>>> #1: "your app repo is moved into some subdirectory >>of a >> >>> cordova >> >>> >> >> > > project >> >>> >> >> > > >>>> -- >> >>> >> >> > > >>>> its exact location is basically a cordova artifact" >> >>> >> >> > > >>>> cordova create Foo >> >>> >> >> > > >>>> cd Foo >> >>> >> >> > > >>>> cordova app add [--link] git-repo/local-repo (nicely >> >>>akin >> >>> to >> >>> >> >> plugin >> >>> >> >> > > >>>> add) >> >>> >> >> > > >>>> cordova plugin/platforms add ... >> >>> >> >> > > >>>> >> >>> >> >> > > >>>> #2: "your app repo becomes a cordova project >>in-place" >> >>> >> >> > > >>>> git clone FooApp (this repo contains merges/ and >>www/) >> >>> >> >> > > >>>> cordova create FooApp Foo (cli should not clobber >> >>>existing >> >>> >> >> folders) >> >>> >> >> > > >>>> cd FooApp >> >>> >> >> > > >>>> set up .gitignore for cordova artifacts (cordova >>should >> >>> try >> >>> >> not >> >>> >> >> to >> >>> >> >> > > >>>> introduce new artifacts) >> >>> >> >> > > >>>> cordova plugin/platforms add ... >> >>> >> >> > > >>>> >> >>> >> >> > > >>>> #3: "what we have now" >> >>> >> >> > > >>>> git clone FooApp >> >>> >> >> > > >>>> cordova create Foo >> >>> >> >> > > >>>> cp -R FooApp/{www,merges,...} Foo (or ln -s) >> >>> >> >> > > >>>> cd Foo >> >>> >> >> > > >>>> cordova plugin/platforms add ... >> >>> >> >> > > >>>> >> >>> >> >> > > >>>> (Please let me know of more workflows) >> >>> >> >> > > >>>> >> >>> >> >> > > >>>> Workflow #1 I think is very clean, and requires an >>app >> >>> folder >> >>> >> >> > concept >> >>> >> >> > > >>>> (we >> >>> >> >> > > >>>> could maybe use a temporary intermediate folder to >>get >> >>> around >> >>> >> >> this, >> >>> >> >> > > but >> >>> >> >> > > >>>> why). >> >>> >> >> > > >>>> Workflow #2 essentially your app repo is the app >>folder >> >>> >> concept, >> >>> >> >> but >> >>> >> >> > > now >> >>> >> >> > > >>>> the cordova artifacts also go inside it. Would >>require >> >>> minimal >> >>> >> >> > > changes >> >>> >> >> > > >>>> to >> >>> >> >> > > >>>> cordova-cli to not clobber, and requires gitignore. >> >>> >> >> > > >>>> Workflow #3 is what we have now, which I think is the >> >>>worst >> >>> >> option >> >>> >> >> > for >> >>> >> >> > > >>>> app >> >>> >> >> > > >>>> management, but can work with or without an app >>folder. >> >>> >> >> > > >>>> >> >>> >> >> > > >>>> >> >>> >> >> > > >>>> Also, I think it would be great if apps had both >>plugin >> >>>and >> >>> >> >> platform >> >>> >> >> > > >>>> dependancies, such that you could distill workflow #1 >> >>>down >> >>> to: >> >>> >> >> > > >>>> >> >>> >> >> > > >>>> cordova create Foo >> >>> >> >> > > >>>> cd Foo >> >>> >> >> > > >>>> cordova app add git-repo >> >>> >> >> > > >>>> >> >>> >> >> > > >>>> .. and it would run the plugin/platform add >> >>>automatically. >> >>> Can >> >>> >> >> even >> >>> >> >> > > get >> >>> >> >> > > >>>> that down to a single "cordova create git-repo" line. >> >>>That >> >>> >> would >> >>> >> >> > make >> >>> >> >> > > >>>> sharing apps, such as mobile-spec-test, really >>trivial. >> >>> >> >> > > >>>> >> >>> >> >> > > >>>> -Michal >> >>> >> >> > > >>>> >> >>> >> >> > > >>>> >> >>> >> >> > > >>>> On Tue, Apr 16, 2013 at 9:19 AM, Andrew Grieve >> >>> >> >> > > >>>> <agri...@chromium.org>wrote: >> >>> >> >> > > >>>> >> >>> >> >> > > >>>>> So, reading through the thread Braden linked to: >> >>> >> >> > > >>>>> >> >>> >> http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html >> >>> >> >> > > >>>>> >> >>> >> >> > > >>>>> There are two advantage that were brought up: >> >>> >> >> > > >>>>> 1. config.xml (configuration) does not live along >>side >> >>>of >> >>> app >> >>> >> >> > > resources >> >>> >> >> > > >>>>> 2. It will make it easier to package apps >> >>> >> >> > > >>>>> - E.g. zip the app/ directory and install it into >>the >> >>> >> >> app-harness >> >>> >> >> > > >>>>> (instead of zipping www + merges). Likewise for >> >>>phonegap >> >>> >> build. >> >>> >> >> > > >>>>> - E.g. cordova-mobile-spec would contain the >>contents >> >>>of >> >>> >> app/. >> >>> >> >> > With >> >>> >> >> > > >>>>> our >> >>> >> >> > > >>>>> current setup, it would contain www/ merges/, and >>have >> >>> the CLI >> >>> >> >> > place >> >>> >> >> > > >>>>> build >> >>> >> >> > > >>>>> artifacts within the repo's directory instead of as >>a >> >>> sibling >> >>> >> to >> >>> >> >> > it. >> >>> >> >> > > >>>>> >> >>> >> >> > > >>>>> I think everyone acknowledged the benefits, but >>there >> >>>was >> >>> >> still >> >>> >> >> > > >>>>> not consensus over whether it was "worth it". >> >>> >> >> > > >>>>> >> >>> >> >> > > >>>>> I don't really feel strongly about it. Braden says >>it's >> >>> easy >> >>> >> to >> >>> >> >> > > change >> >>> >> >> > > >>>>> code-wise. Does anyone want to go to bat for it? >> >>> >> >> > > >>>>> >> >>> >> >> > > >>>>> >> >>> >> >> > > >>>>> >> >>> >> >> > > >>>>> On Mon, Apr 15, 2013 at 6:59 PM, Brian LeRoux >> >>><b...@brian.io >> >>> > >> >>> >> >> wrote: >> >>> >> >> > > >>>>> >> >>> >> >> > > >>>>>> I'd rather we did not go ahead w/ the new directory >> >>> >> structure. >> >>> >> >> It >> >>> >> >> > > >>>>> offers no >> >>> >> >> > > >>>>>> functional benefit, and comes at an upgrade cost >>for >> >>>ppl >> >>> >> using >> >>> >> >> the >> >>> >> >> > > >>>>> CLI >> >>> >> >> > > >>>>>> tools today. >> >>> >> >> > > >>>>>> >> >>> >> >> > > >>>>>> >> >>> >> >> > > >>>>>> On Mon, Apr 15, 2013 at 12:46 PM, Andrew Grieve < >> >>> >> >> > > agri...@chromium.org >> >>> >> >> > > >>>>>>> wrote: >> >>> >> >> > > >>>>>> >> >>> >> >> > > >>>>>>> Just catching up on the past week of emails and >>it's >> >>>not >> >>> >> clear >> >>> >> >> > that >> >>> >> >> > > >>>>> there >> >>> >> >> > > >>>>>>> was a consensus here. By the sounds of it though: >> >>> >> >> > > >>>>>>> >> >>> >> >> > > >>>>>>> 1. Lots of users are using Cordova-CLI (master >> >>>branch) >> >>> >> >> > > >>>>>>> 2. Cordova-CLI's "future" branch has >> >>> >> non-backwards-compatible >> >>> >> >> > > >>>>> changes. >> >>> >> >> > > >>>>>>> 3. One of these changes is the directory >>structure. >> >>> >> >> > > >>>>>>> >> >>> >> >> > > >>>>>>> The main debate is on how to message these >>changes to >> >>> users. >> >>> >> >> What >> >>> >> >> > > >>>>> we >> >>> >> >> > > >>>>>> should >> >>> >> >> > > >>>>>>> do is: >> >>> >> >> > > >>>>>>> >> >>> >> >> > > >>>>>>> 1. Have an upgrade guide. (e.g. paths are now >> >>>relative >> >>> to >> >>> >> >> > > >>>>> plugin.xml) >> >>> >> >> > > >>>>>>> 2. Ensure that our error handling shows useful >> >>>messages >> >>> when >> >>> >> >> they >> >>> >> >> > > >>>>> result >> >>> >> >> > > >>>>>>> from an old-way-of-doing-things (e.g. your app's >> >>> structure >> >>> >> >> > doesn't >> >>> >> >> > > >>>>>> match.) >> >>> >> >> > > >>>>>>> >> >>> >> >> > > >>>>>>> Rather than printing out the commands to run to >> >>>convert >> >>> >> their >> >>> >> >> > > >>>>> project, >> >>> >> >> > > >>>>>>> maybe we could have them in the upgrade guide and >> >>>have >> >>> the >> >>> >> >> error >> >>> >> >> > > >>>>> messages >> >>> >> >> > > >>>>>>> point to the guide? >> >>> >> >> > > >>>>>>> >> >>> >> >> > > >>>>>>> >> >>> >> >> > > >>>>>>> >> >>> >> >> > > >>>>>>> >> >>> >> >> > > >>>>>>> On Wed, Apr 10, 2013 at 5:47 PM, Tim Kim < >> >>> >> timki...@gmail.com> >> >>> >> >> > > >>>>> wrote: >> >>> >> >> > > >>>>>>> >> >>> >> >> > > >>>>>>>> Braden I have merged master and the future >>branch: >> >>> >> >> > > >>>>>>>> >> >>> https://github.com/timkim/plugman/tree/future_master_merge >> >>> >> >> > > >>>>>>>> >> >>> >> >> > > >>>>>>>> I think it's about ready to merge back in to >>future. >> >>> I've >> >>> >> >> gotten >> >>> >> >> > > >>>>> the >> >>> >> >> > > >>>>>>>> android-one-install and the >>ios-config-xml-install >> >>> (minus >> >>> >> one >> >>> >> >> > > >>>>> weird >> >>> >> >> > > >>>>>> test >> >>> >> >> > > >>>>>>> I >> >>> >> >> > > >>>>>>>> don't understand) working. >> >>> >> >> > > >>>>>>>> >> >>> >> >> > > >>>>>>>> >> >>> >> >> > > >>>>>>>> On 10 April 2013 14:42, Anis KADRI < >> >>> anis.ka...@gmail.com> >> >>> >> >> > wrote: >> >>> >> >> > > >>>>>>>> >> >>> >> >> > > >>>>>>>>> As far as I am concerned I don't really have a >> >>>strong >> >>> >> opinion >> >>> >> >> > > >>>>> on >> >>> >> >> > > >>>>> this >> >>> >> >> > > >>>>>>>>> topic. As I said in the previous thread, I do >>like >> >>> this >> >>> >> new >> >>> >> >> > > >>>>> directory >> >>> >> >> > > >>>>>>>>> structure and if you have it there and tested >>then >> >>> fine. >> >>> >> We >> >>> >> >> > > >>>>> break >> >>> >> >> > > >>>>>> shit >> >>> >> >> > > >>>>>>>> all >> >>> >> >> > > >>>>>>>>> the time it's not like this change is one too >>many. >> >>> What >> >>> >> >> > > >>>>> matters >> >>> >> >> > > >>>>> is >> >>> >> >> > > >>>>>> to >> >>> >> >> > > >>>>>>>>> communicate it to our users and give them an >> >>>upgrade >> >>> path >> >>> >> to >> >>> >> >> > > >>>>> this >> >>> >> >> > > >>>>> new >> >>> >> >> > > >>>>>>> app >> >>> >> >> > > >>>>>>>>> structure (the Cordova docs are a good place for >> >>> that). >> >>> >> >> > > >>>>>>>>> >> >>> >> >> > > >>>>>>>>> However, I agree with Brian that there are more >> >>> important >> >>> >> >> > > >>>>> things >> >>> >> >> > > >>>>> to >> >>> >> >> > > >>>>>>>> tackle >> >>> >> >> > > >>>>>>>>> right now. Now sure what you had on your list >>but >> >>> since js >> >>> >> >> only >> >>> >> >> > > >>>>>> modules >> >>> >> >> > > >>>>>>>> are >> >>> >> >> > > >>>>>>>>> in Plugman right now (untested) The next big >>thing >> >>> that is >> >>> >> >> > > >>>>> going >> >>> >> >> > > >>>>> to >> >>> >> >> > > >>>>>> be >> >>> >> >> > > >>>>>>>>> non-trivial is: plugin dependencies (which will >>in >> >>> some >> >>> >> ways >> >>> >> >> > > >>>>> involve >> >>> >> >> > > >>>>>>>>> discovery I think). We should have a discussion >> >>>about >> >>> that >> >>> >> >> > > >>>>> (hangout, >> >>> >> >> > > >>>>>>> IRC, >> >>> >> >> > > >>>>>>>>> connect...whatever). I have a couple of ideas >>about >> >>> that. >> >>> >> >> > > >>>>>>>>> >> >>> >> >> > > >>>>>>>>> Tim is working on fixing/adding/updating plugman >> >>>tests >> >>> >> and it >> >>> >> >> > > >>>>> looks >> >>> >> >> > > >>>>>>> like >> >>> >> >> > > >>>>>>>>> he's making good progress on it. >> >>> >> >> > > >>>>>>>>> >> >>> >> >> > > >>>>>>>>> -a >> >>> >> >> > > >>>>>>>>> >> >>> >> >> > > >>>>>>>>> >> >>> >> >> > > >>>>>>>>> On Wed, Apr 10, 2013 at 11:53 AM, Michael Wolf < >> >>> >> >> > > >>>>>>> michael.w...@cynergy.com >> >>> >> >> > > >>>>>>>>>> wrote: >> >>> >> >> > > >>>>>>>>> >> >>> >> >> > > >>>>>>>>>> +1 >> >>> >> >> > > >>>>>>>>>> >> >>> >> >> > > >>>>>>>>>> I get the intention, however anything we can >>do to >> >>> reduce >> >>> >> >> > > >>>>> this >> >>> >> >> > > >>>>> type >> >>> >> >> > > >>>>>>> of >> >>> >> >> > > >>>>>>>>>> breaking change should be done. These type of >> >>> changes >> >>> >> >> > > >>>>> should >> >>> >> >> > > >>>>> be >> >>> >> >> > > >>>>>>>>>> considered for major releases only so users can >> >>>plan >> >>> for >> >>> >> >> > > >>>>> them. >> >>> >> >> > > >>>>>>>>>> >> >>> >> >> > > >>>>>>>>>> mw >> >>> >> >> > > >>>>>>>>>> >> >>> >> >> > > >>>>>>>>>> On 4/9/13 5:05 PM, "Jesse" >> >>><purplecabb...@gmail.com> >> >>> >> wrote: >> >>> >> >> > > >>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>> +1 to the sanity plea of devgeek Tommy >> >>> >> >> > > >>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>> Also, if it didn't happen on this list, .... >> >>> >> >> > > >>>>>>>>>>> 'Consensus' should always be tracked back to a >> >>> thread >> >>> >> here, >> >>> >> >> > > >>>>>>> regardless >> >>> >> >> > > >>>>>>>>> of >> >>> >> >> > > >>>>>>>>>>> meetings, hangouts, irc, bbs, ... >> >>> >> >> > > >>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>> @purplecabbage >> >>> >> >> > > >>>>>>>>>>> risingj.com >> >>> >> >> > > >>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>> On Tue, Apr 9, 2013 at 1:48 PM, tommy-carlos >> >>> Williams >> >>> >> >> > > >>>>>>>>>>> <to...@devgeeks.org>wrote: >> >>> >> >> > > >>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>>> Sorry, but as someone that helps users >>everyday, >> >>> the >> >>> >> >> > > >>>>> almost >> >>> >> >> > > >>>>>> "it's >> >>> >> >> > > >>>>>>>>> alpha, >> >>> >> >> > > >>>>>>>>>>>> they shoulda seen it coming" tone of this is >>a >> >>>bit >> >>> >> >> > > >>>>> upsetting. >> >>> >> >> > > >>>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>>> It reminds me of before the deprecation >>policy, >> >>>etc >> >>> >> when >> >>> >> >> > > >>>>>> PhoneGap >> >>> >> >> > > >>>>>>>>> would >> >>> >> >> > > >>>>>>>>>>>> completely break everything whenever a new >> >>>version >> >>> came >> >>> >> >> > > >>>>> out. >> >>> >> >> > > >>>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>>> I feel like we have come a long way since >>then >> >>> (with a >> >>> >> >> > > >>>>> ways >> >>> >> >> > > >>>>>> still >> >>> >> >> > > >>>>>>> to >> >>> >> >> > > >>>>>>>>> go, >> >>> >> >> > > >>>>>>>>>>>> no question about it). I would hate to be >>the >> >>>one >> >>> in >> >>> >> IRC >> >>> >> >> > > >>>>> and on >> >>> >> >> > > >>>>>>> the >> >>> >> >> > > >>>>>>>>>>>> Google >> >>> >> >> > > >>>>>>>>>>>> Group list having to explain this to everyone >> >>> using the >> >>> >> >> > > >>>>> cli. >> >>> >> >> > > >>>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>>> I was under the impression that the cli was >> >>> "shipping" >> >>> >> >> > > >>>>> now, >> >>> >> >> > > >>>>> not >> >>> >> >> > > >>>>>>>> just a >> >>> >> >> > > >>>>>>>>>>>> little side thing. I know that quite a few >> >>>people >> >>> are >> >>> >> >> > > >>>>> using >> >>> >> >> > > >>>>> it >> >>> >> >> > > >>>>>> for >> >>> >> >> > > >>>>>>>>> real >> >>> >> >> > > >>>>>>>>>>>> apps (myself included). If that is true, >>then we >> >>> have a >> >>> >> >> > > >>>>> duty >> >>> >> >> > > >>>>> to >> >>> >> >> > > >>>>>> at >> >>> >> >> > > >>>>>>>>> least >> >>> >> >> > > >>>>>>>>>>>> think very carefully before breaking >>something >> >>>and >> >>> >> come up >> >>> >> >> > > >>>>> with >> >>> >> >> > > >>>>>> a >> >>> >> >> > > >>>>>>>> good >> >>> >> >> > > >>>>>>>>>>>> plan >> >>> >> >> > > >>>>>>>>>>>> for easing that transition. >> >>> >> >> > > >>>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>>> - tommy >> >>> >> >> > > >>>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>>> On 10/04/2013, at 1:40, Braden Shepherdson < >> >>> >> >> > > >>>>> bra...@chromium.org >> >>> >> >> > > >>>>>>> >> >>> >> >> > > >>>>>>>>> wrote: >> >>> >> >> > > >>>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>>>> This mailing list post is, or will shortly >>be, >> >>> indexed >> >>> >> >> > > >>>>> by >> >>> >> >> > > >>>>>> Google >> >>> >> >> > > >>>>>>>> and >> >>> >> >> > > >>>>>>>>>>>>> others. Any newcomers will see the new docs >>and >> >>> create >> >>> >> >> > > >>>>> new >> >>> >> >> > > >>>>>>>> projects. >> >>> >> >> > > >>>>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>>>> As I mentioned on IRC, existing users are >> >>>either >> >>> >> >> > > >>>>> accepting >> >>> >> >> > > >>>>> or >> >>> >> >> > > >>>>>>>>> ignoring >> >>> >> >> > > >>>>>>>>>>>> the >> >>> >> >> > > >>>>>>>>>>>>> "alpha" warnings that this software is new >>and >> >>> under >> >>> >> >> > > >>>>> heavy >> >>> >> >> > > >>>>>>>>>>>> development, >> >>> >> >> > > >>>>>>>>>>>> and >> >>> >> >> > > >>>>>>>>>>>>> if they want to jump on it early they're >>going >> >>>to >> >>> have >> >>> >> >> > > >>>>> to >> >>> >> >> > > >>>>>> expect >> >>> >> >> > > >>>>>>>>> some >> >>> >> >> > > >>>>>>>>>>>> pain. >> >>> >> >> > > >>>>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>>>> That said, I don't really know of any better >> >>>way >> >>> to >> >>> >> >> > > >>>>> socialize >> >>> >> >> > > >>>>>>> it. >> >>> >> >> > > >>>>>>>> Is >> >>> >> >> > > >>>>>>>>>>>> there >> >>> >> >> > > >>>>>>>>>>>>> anywhere where a brief blog post on this >>would >> >>> make >> >>> >> >> > > >>>>> sense? >> >>> >> >> > > >>>>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>>>> I don't know how many people are using these >> >>> tools and >> >>> >> >> > > >>>>> not >> >>> >> >> > > >>>>> on >> >>> >> >> > > >>>>>>> the >> >>> >> >> > > >>>>>>>>>>>> mailing >> >>> >> >> > > >>>>>>>>>>>>> list, though certainly some turn up on IRC >> >>> >> occasionally. >> >>> >> >> > > >>>>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>>>> Braden >> >>> >> >> > > >>>>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>>>> On Tue, Apr 9, 2013 at 11:24 AM, Filip Maj >> >>> >> >> > > >>>>> <f...@adobe.com> >> >>> >> >> > > >>>>>>> wrote: >> >>> >> >> > > >>>>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>>>>> How will we communicate this change to our >> >>> existing >> >>> >> >> > > >>>>> users? >> >>> >> >> > > >>>>>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>>>>> On 4/9/13 5:22 PM, "Braden Shepherdson" < >> >>> >> >> > > >>>>> bra...@chromium.org >> >>> >> >> > > >>>>>>> >> >>> >> >> > > >>>>>>>>> wrote: >> >>> >> >> > > >>>>>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>>>>>> I've just pushed a change to the future >> >>>branch >> >>> that >> >>> >> >> > > >>>>> changes >> >>> >> >> > > >>>>>>> the >> >>> >> >> > > >>>>>>>>>>>> directory >> >>> >> >> > > >>>>>>>>>>>>>>> structure to: >> >>> >> >> > > >>>>>>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>>>>>> app/ >> >>> >> >> > > >>>>>>>>>>>>>>> merges/ >> >>> >> >> > > >>>>>>>>>>>>>>> android/ >> >>> >> >> > > >>>>>>>>>>>>>>> ios/ >> >>> >> >> > > >>>>>>>>>>>>>>> www/ >> >>> >> >> > > >>>>>>>>>>>>>>> config.xml >> >>> >> >> > > >>>>>>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>>>>>> As was discussed at our video conference >> >>> meeting a >> >>> >> >> > > >>>>> couple of >> >>> >> >> > > >>>>>>>> weeks >> >>> >> >> > > >>>>>>>>>>>> ago, >> >>> >> >> > > >>>>>>>>>>>>>>> this has a number of advantages: >> >>> >> >> > > >>>>>>>>>>>>>>> - config.xml is no longer in the www/ >> >>>directory >> >>> >> >> > > >>>>>>>>>>>>>>> - One can easily version control the whole >> >>>app/ >> >>> >> >> > > >>>>> directory, >> >>> >> >> > > >>>>>> and >> >>> >> >> > > >>>>>>>> get >> >>> >> >> > > >>>>>>>>>>>> their >> >>> >> >> > > >>>>>>>>>>>>>>> web assets, merges and so on into the >>repo. >> >>> >> >> > > >>>>>>>>>>>>>>> - That repo can contain additional >> >>>information: >> >>> a >> >>> >> >> > > >>>>> README.md, >> >>> >> >> > > >>>>>>>>>>>> supplementary >> >>> >> >> > > >>>>>>>>>>>>>>> documentation, tests, whatever. The CLI >>will >> >>> ignore >> >>> >> >> > > >>>>> anything >> >>> >> >> > > >>>>>>>>>>>> outside of >> >>> >> >> > > >>>>>>>>>>>>>>> the >> >>> >> >> > > >>>>>>>>>>>>>>> merges and www directories. >> >>> >> >> > > >>>>>>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>>>>>> The downside is that this is a breaking >> >>>change: >> >>> >> >> > > >>>>> running >> >>> >> >> > > >>>>> the >> >>> >> >> > > >>>>>>> new >> >>> >> >> > > >>>>>>>>>>>> version of >> >>> >> >> > > >>>>>>>>>>>>>>> the tools on an old project will fail >>(but I >> >>> think >> >>> >> in >> >>> >> >> > > >>>>> a >> >>> >> >> > > >>>>>>> harmless >> >>> >> >> > > >>>>>>>>>>>> way) >> >>> >> >> > > >>>>>>>>>>>>>>> until >> >>> >> >> > > >>>>>>>>>>>>>>> you rearrange the directories. You can do >> >>>that >> >>> with >> >>> >> >> > > >>>>> the >> >>> >> >> > > >>>>>>>> following >> >>> >> >> > > >>>>>>>>>>>>>>> commands: >> >>> >> >> > > >>>>>>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>>>>>> $ mkdir app >> >>> >> >> > > >>>>>>>>>>>>>>> $ mv www/config.xml app >> >>> >> >> > > >>>>>>>>>>>>>>> $ mv www app >> >>> >> >> > > >>>>>>>>>>>>>>> $ mv merges app >> >>> >> >> > > >>>>>>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>>>>>> All docs and tests are updated as well. >>Any >> >>> problems >> >>> >> >> > > >>>>> should >> >>> >> >> > > >>>>>> be >> >>> >> >> > > >>>>>>>>>>>> reported on >> >>> >> >> > > >>>>>>>>>>>>>>> JIRA and assigned to me. >> >>> >> >> > > >>>>>>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>>>>>> Braden >> >>> >> >> > > >>>>>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>>>> >> >>> >> >> > > >>>>>>>>>> >> >>> >> >> > > >>>>>>>>>> >> >>> >> >> > > >>>>>>>>> >> >>> >> >> > > >>>>>>>> >> >>> >> >> > > >>>>>>>> >> >>> >> >> > > >>>>>>>> >> >>> >> >> > > >>>>>>>> -- >> >>> >> >> > > >>>>>>>> Timothy Kim >> >>> >> >> > > >>>>>>>> >> >>> >> >> > > >>>>>>> >> >>> >> >> > > >>>>>> >> >>> >> >> > > >>>>> >> >>> >> >> > > >>>> >> >>> >> >> > > >>>> >> >>> >> >> > > >> >> >>> >> >> > > >> >>> >> >> > > >> >>> >> >> > >> >>> >> >> >> >>> >> >> >>> >> >> >> >> >> >>
