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 16:27:07 GMT
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:j76xli
>> >> >> > > >> hsfjmvwtoi+state:results
>> >> >> > > >> B)
>> >> http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html
>> >> >> > > >>
>> >> >> > > >> Arguments for moving to app/:
>> >> >> > > >>
>> >> >> > > >> - easier to version control relevant / non-build-artifact app
>> >> bits
>> >> >> > > >> - aesthetics
>> >> >> > > >>
>> >> >> > > >> Arguments against it:
>> >> >> > > >>
>> >> >> > > >> - we break shit for users
>> >> >> > > >> - config.xml location and PhoneGap Build compatibility (but I
>> >> don't
>> >> >> > see
>> >> >> > > >> this as a valid argument against. This is an easy problem to
>> >> solve
>> >> >> for
>> >> >> > > us
>> >> >> > > >> Adobe folk and the tooling can handle the trivial steps of
>> going
>> >> up
>> >> >> > one
>> >> >> > > >> directory to grab the right file before interfacing with
>> Build)
>> >> >> > > >>
>> >> >> > > >> Also worth noting: people we're not against it for
>> architectural
>> >> >> > > reasons,
>> >> >> > > >> in fact, most people were favorable for the change to app/.
>> >> >> > > >>
>> >> >> > > >> So, with plugman stabilizing and my focus moving to cli
>> work, I
>> >> >> feel I
>> >> >> > > >> have a good grasp of both projects and the direction they are
>> >> going,
>> >> >> > > here
>> >> >> > > >> is my suggestion on how to move forward with this:
>> >> >> > > >>
>> >> >> > > >> 1. cordova-cli's master branch, which will soon merge future
>> work
>> >> >> in,
>> >> >> > > will
>> >> >> > > >> revert to the old /www-based structure, then
>> >> >> > > >> 2. In 3.0 we make the change, where landing such a breaking
>> >> change
>> >> >> is
>> >> >> > > >> easier and we'll have a bunch of press/noise about the
>> release
>> >> out
>> >> >> > there
>> >> >> > > >> too so communicating this change would be easier.
>> >> >> > > >>
>> >> >> > > >> If there are any other arguments for/against the app/ based
>> >> >> structure,
>> >> >> > > now
>> >> >> > > >> is the time to bring it up. We can give this some more time
>> to
>> >> bake,
>> >> >> > but
>> >> >> > > >> after 2.8 is released, I'd like to call a vote on whether we
>> >> should
>> >> >> > move
>> >> >> > > >> to this structure or not in 3.0.
>> >> >> > > >>
>> >> >> > > >> On 4/16/13 8:31 AM, "Michal Mocny" <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