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