cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Wolf <Michael.W...@Cynergy.com>
Subject Re: New directory structure in cordova-cli's future branch
Date Sun, 26 May 2013 14:46:15 GMT
+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" <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: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" <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
View raw message