+1 to making a change in 3.0. As a user I would expect major changes and wouldn't be bothered by changes at that time. I would also add that this isn't just a break for users of the cli, but also for users who create their own build systems.
mw On 5/23/13 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:j7 >>>>6 >>>>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 >>>> >> >> > > >>>>>>>> >>>> >> >> > > >>>>>>> >>>> >> >> > > >>>>>> >>>> >> >> > > >>>>> >>>> >> >> > > >>>> >>>> >> >> > > >>>> >>>> >> >> > > >> >>>> >> >> > > >>>> >> >> > > >>>> >> >> > >>>> >> >> >>>> >> >>>> >>> >>> >
