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:j76xli >> >> >> > > >> 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 >> >> >> > > >>>>>>>> >> >> >> > > >>>>>>> >> >> >> > > >>>>>> >> >> >> > > >>>>> >> >> >> > > >>>> >> >> >> > > >>>> >> >> >> > > >> >> >> >> > > >> >> >> > > >> >> >> > >> >> >> >> >> >> > >
