Also this is assuming your making no changes to Platforms, and I among
others often make changes to the native containers, which then must be
checked in.
mw
On 5/23/13 11:47 AM, Brian LeRoux b...@brian.io wrote:
Not buying that either. The `./app` directory lives in the root so
everything will
+1
to making a change in 3.0. As a user I would expect major changes and
wouldn't be bothered by changes at that time. I would also add that this
isn't just a break for users of the cli, but also for users who create
their own build systems.
mw
On 5/23/13 12:32 PM, Filip Maj f...@adobe.com
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
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
Fil, that sounds extremely sensible.
On Thu, May 23, 2013 at 12:32 PM, Filip Maj f...@adobe.com wrote:
https://npmjs.org/package/cordova
While CLI is not a documented flow, it is deployed and has 1000
downloads per month.
That's my only concern: not fucking those people over.
I'm in
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
+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 f...@adobe.com wrote:
So for the sake of moving the RC release along,
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
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)
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.
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
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
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
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/
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
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
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
I'd rather we did not go ahead w/ the new directory structure. It offers no
functional benefit, and comes at an upgrade cost for ppl using the CLI
tools today.
On Mon, Apr 15, 2013 at 12:46 PM, Andrew Grieve agri...@chromium.orgwrote:
Just catching up on the past week of emails and it's not
First, note that this change is in the future branch. The future branch has
several other breaking changes aside from this one:
- It changes the plugin spec significantly (adding js-module, changing
paths in source-file etc. from magic to relative-to-plugin.xml) which
will require updates of any
I agree that option 2 is the best route. There's no real need to support
the old style if it's made dead easy to move to the new style, and I
haven't seen any arguments for the old style being superior.
On Wed, Apr 10, 2013 at 11:36 AM, Braden Shepherdson bra...@chromium.orgwrote:
First, note
+1
I get the intention, however anything we can do to reduce this type of
breaking change should be done. These type of changes should be
considered for major releases only so users can plan for them.
mw
On 4/9/13 5:05 PM, Jesse purplecabb...@gmail.com wrote:
+1 to the sanity plea of devgeek
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
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
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
How will we communicate this change to our existing users?
On 4/9/13 5:22 PM, Braden Shepherdson bra...@chromium.org wrote:
I've just pushed a change to the future branch that changes the directory
structure to:
app/
merges/
android/
ios/
www/
config.xml
As was
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
For a couple months now the npm package has had about 1000 downloads per
month [1].
We do have upgrade guides in our docs for each version for each platform.
Maybe we could add a CLI section? Then we can reference those guides in
the CLI's readme? Just thinking out loud.
[1]
:(
We never had full consensus to do this Braden.
On Tuesday, April 9, 2013, Filip Maj wrote:
For a couple months now the npm package has had about 1000 downloads per
month [1].
We do have upgrade guides in our docs for each version for each platform.
Maybe we could add a CLI section? Then
That's now how I recalled the discussion. It certainly wasn't clear-cut,
but I thought the conclusion was that this was fine.
Well, then this is now a discussion thread. What are the counterarguments?
Braden
On Tue, Apr 9, 2013 at 2:49 PM, Brian LeRoux b...@brian.io wrote:
:(
We never had
I'm still not sold on the new directory structure, but I would need to
review the previous thread on why we are interested in adopting it.
A minor concern on my part is the placement of `config.xml`.
The path to `index.html` must be referenced relative to `config.xml` [1].
Since `config.xml` is
I did think about this in the back of my mind when moving the config.xml. I
don't think bending this spec and letting the paths in config.xml continue
to be relative to www/ is that terrible. We break the Widget spec in a
quite a number of other ways anyway.
It would be a tiny change to put it
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
+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
I can't say I have strong feelings one way or the other.
I will say that having config.xml inside www *does* feel odd. So I'd be all for
moving it to the project's root directory (but that breaks spec. Is that good?
Bad?). Which is a breaking change, and so we'd still have to deal with older
34 matches
Mail list logo
