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