cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: New directory structure in cordova-cli's future branch
Date Thu, 23 May 2013 19:52:25 GMT
Sure, move the RC along so we can discuss calmly.

-Michal


On Thu, May 23, 2013 at 2:31 PM, Brian LeRoux <b@brian.io> wrote:

> +1
>
> Lets start a fresh thread that describes the problem discreetly and
> work out a solution together. I suspect we'll arrive at a different
> solution than moving folders around.
>
>
> On Thu, May 23, 2013 at 11:04 AM, Filip Maj <fil@adobe.com> wrote:
> > So for the sake of moving the RC release along, Michal/Braden/Andrew are
> > you guys cool if we:
> >
> > A) revert to www/ as root folder
> > B) proceed with 2.8.0rc1 tagging
> > C) continue with this discussion to try to get to a resolution.
> Worst-case
> > we call a vote next week?
> >
> > On 5/23/13 10:56 AM, "Michal Mocny" <mmocny@chromium.org> wrote:
> >
> >>Fil, that sounds extremely sensible.
> >>
> >>
> >>On Thu, May 23, 2013 at 12:32 PM, Filip Maj <fil@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" <mmocny@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 <mmocny@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
> >>> >>><braden@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 <
> >>> >>> braden@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
> >>> >>><mmocny@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 <
> >>> >>> agrieve@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
> >>> >>> >> >> > <tommy@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
> >>><fil@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"
> >>><mmocny@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 <
> >>> >>> >> >> mmocny@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
> >>> >>> >> >> > > >>>> <agrieve@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 <
> >>> >>> >> >> > > agrieve@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 <
> >>> >>> >> timkim85@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.kadri@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.Wolf@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"
> >>> >>><purplecabbage@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
> >>> >>> >> >> > > >>>>>>>>>>> <tommy@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 <
> >>> >>> >> >> > > >>>>> braden@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
> >>> >>> >> >> > > >>>>> <fil@adobe.com>
> >>> >>> >> >> > > >>>>>>> wrote:
> >>> >>> >> >> > > >>>>>>>>>>>>>
> >>> >>> >> >> > > >>>>>>>>>>>>>> How will we communicate this change to our
> >>> >>> existing
> >>> >>> >> >> > > >>>>> users?
> >>> >>> >> >> > > >>>>>>>>>>>>>>
> >>> >>> >> >> > > >>>>>>>>>>>>>> On 4/9/13 5:22 PM, "Braden Shepherdson" <
> >>> >>> >> >> > > >>>>> braden@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
> >>> >>> >> >> > > >>>>>>>>
> >>> >>> >> >> > > >>>>>>>
> >>> >>> >> >> > > >>>>>>
> >>> >>> >> >> > > >>>>>
> >>> >>> >> >> > > >>>>
> >>> >>> >> >> > > >>>>
> >>> >>> >> >> > > >>
> >>> >>> >> >> > >
> >>> >>> >> >> > >
> >>> >>> >> >> >
> >>> >>> >> >>
> >>> >>> >>
> >>> >>>
> >>> >>
> >>> >>
> >>>
> >>>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message