Will do, it's on my compatibility list of things to do. Thanks PJ
On Wed, Sep 4, 2013 at 3:42 AM, Andrew Grieve wrote:
> Shaz, can you test this fix? (I haven't gotten on the 4.5 bandwagon yet)
>
>
> On Tue, Sep 3, 2013 at 10:59 AM, PJ Dillon wrote:
>
> > For our purposes, CDVSplashScreen.m (a
If URL can be relative, why do we need a new path parameter? All we would
need is to treat leading ./ or ../ as relative to the plugin not root,
which I think is fine.
I'll sleep on it and draw it out on whiteboard tomorrow to make sure all
the cases are handled.
On Tue, Sep 3, 2013 at 11:56 PM
Agree the use-case is valid. Here's a variation on (1) that I think is
marginally nicer:
url="." to be made optional, but default value is "."
subdir="" works only with git repos and is always relative to the root of
the repo.
path="" works with git repos or local paths and is relative to the
plug
likely need to update your node_modules.
On Tue, Sep 3, 2013 at 7:25 PM, Joe Bowser wrote:
> Hey
>
> I just pulled the latest Cordova JS and I noticed that urlutil has
> failing tests. What is urlutil for, and why are the tests failing?
> Should I care about this beyond the fact that I dislike
Just to loop back on this - I've updated the
https://wiki.apache.org/cordova/CommitterWorkflow to include a section at
the bottom on which branch to commit against.
On Thu, Aug 29, 2013 at 4:00 PM, Becky Gibson wrote:
> Yes, updating the wiki would be helpful. I'd like to submit a fix but
> sin
Zapped.
On Tue, Sep 3, 2013 at 8:37 PM, Simon MacDonald
wrote:
> Can we get them off the docs website as well? They don't provide much
> value once the release is officially out.
> Simon Mac Donald
> http://hi.im/simonmacdonald
>
>
> On Tue, Sep 3, 2013 at 8:25 PM, Tommy-Carlos Williams
> wrote
Mulling this over a bit, I think I would like a solution for specifying
dependancies that would work regardless of where/how the plugins are
hosted, git or local. If you had:
BB_PLUGINS/
- plug1/
- plug2/
...
(and plug1 depends on plug2), then:
cordova plugin add LOCAL/PATH/TO/BB_PLUGINS/plug1
Sounds reasonable to me.
Conceptually, I'm not sure why the syntax for (2) shouldn't do what you
request when the url for the original plugin was a local path? Maybe just
a bug?
-Michal
On Tue, Sep 3, 2013 at 9:38 PM, Jeffrey Heifetz wrote:
> We were working on a redistribution of Cordova tha
We were working on a redistribution of Cordova that included some plugins and
ran into a use-case not covered by the current plugin spec.[1]
Currently there are two ways to specify a dependency
1. Using a combination of url, commit and subdir which plugman will use to
clone down a repo and insta
Can we get them off the docs website as well? They don't provide much
value once the release is officially out.
Simon Mac Donald
http://hi.im/simonmacdonald
On Tue, Sep 3, 2013 at 8:25 PM, Tommy-Carlos Williams
wrote:
> +1
>
> I think they even actively add confusion.
>
>
>
> On 04/09/2013, at 2
+1
I think they even actively add confusion.
On 04/09/2013, at 2:37 AM, Brian LeRoux wrote:
> go for it, says I
>
>
> On Tue, Sep 3, 2013 at 7:19 AM, Andrew Grieve wrote:
>
>> Anyone opposed if I delete the old rc versions of docs
>> (e.g. ite/public/docs/en/1.9.0rc1)
>>
>> They bloat th
Right now CLI & plugman don't have git tags associated with their npm
releases.
I'd like to be able to do a "git log latest..master" in order to enumerate
changes since the last release.
So, I'd like to propose:
#1 - Add a git tag for each npm release, where the tag name is the same as
the versio
Hey
I just pulled the latest Cordova JS and I noticed that urlutil has
failing tests. What is urlutil for, and why are the tests failing?
Should I care about this beyond the fact that I dislike failing tests?
Joe
Shaz, can you test this fix? (I haven't gotten on the 4.5 bandwagon yet)
On Tue, Sep 3, 2013 at 10:59 AM, PJ Dillon wrote:
> For our purposes, CDVSplashScreen.m (as of 2.9.0) just needed a test for
> the OS version when calculating the image bounds:
>
> diff --git a/CordovaLib/Classes/CDVSplash
I think we've had that feature request before (specifically referring to
iOS console Logger plugin, being an optional dependency of the platform).
I don't think its been implemented, and I cannot find a JIRA issue, so
filed: CB-4735
-Michal
On Tue, Sep 3, 2013 at 2:56 PM, Jonathan Bond-Caron wr
This would be my ideal workflow
$ cordova plugin add /path/to/plugin
$ cordova plugin watch /path/to/plugin # detects if plugin is
installed (otherwise fails), watches for changes and automatically
updates CLIPROJECT/plugins and re-runs prepare.
maybe even `add --watch` (CTRL+C to cancel).
We do
+1 for #2
On Tue, Sep 3, 2013 at 11:38 AM, Anis KADRI wrote:
> +1 for number 2
>
> On Tue, Sep 3, 2013 at 10:16 AM, David Kemp wrote:
>> +1 for #2 as well
>>
>>
>> On Tue, Sep 3, 2013 at 1:10 PM, Braden Shepherdson
>> wrote:
>>
>>> +1 for #2.
>>>
>>>
>>> On Tue, Sep 3, 2013 at 12:55 PM, Michal
Volunteer maps well to hows its been done implicitly. If you cannot take a
given week, find a sensible replacement.
Rotation among willing folks makes some sense in terms of passing down of
knowledge.
-Michal
On Tue, Sep 3, 2013 at 12:51 PM, Andrew Grieve wrote:
> I brought up this idea befo
You will need to run:
ripple emulate --path /path/to/cordova/project/platform/android/assets/www
Let me know if that works for you.
On Tue, Sep 3, 2013 at 12:27 PM, Ray Camden wrote:
> Ok, I forgot to run cordova serve. I did, and then I get the same behavior
> as before. A prompt and then in
On Tue, Sep 3, 2013 at 10:09 AM, Brian LeRoux wrote:
> Or you could create cordova-plugin-core, cordova-plugin-chromeos, and
> cordova-plugin-phonegap repos, with a plugin.xml that have the dependencies
> you describe to achieve the same result.
>
> As the other guys mentoin, there's many ways to
On Tue Sep 3 01:09 PM, Brian LeRoux wrote:
> Or you could create cordova-plugin-core, cordova-plugin-chromeos, and
> cordova-plugin-phonegap repos, with a plugin.xml that have the
> dependencies
> you describe to achieve the same result.
>
> As the other guys mentoin, there's many ways to do this
+1 for number 2
On Tue, Sep 3, 2013 at 10:16 AM, David Kemp wrote:
> +1 for #2 as well
>
>
> On Tue, Sep 3, 2013 at 1:10 PM, Braden Shepherdson wrote:
>
>> +1 for #2.
>>
>>
>> On Tue, Sep 3, 2013 at 12:55 PM, Michal Mocny wrote:
>>
>> > +1 for option #2
>> >
>> >
>> > On Tue, Sep 3, 2013 at 12:2
+1
On Tue, Sep 3, 2013 at 10:22 AM, David Kemp wrote:
> I like it - for clarity - I also think that the CLI and plugman should be
> on the same day
>
>
> On Tue, Sep 3, 2013 at 1:12 PM, Braden Shepherdson wrote:
>
>> Agreed, I think this works.
>>
>> I share the hope that the frequency will drop.
Hi,
could a committer please look at this pull request and maybe merge it into
master if ok?
thanks
Axel
https://github.com/apache/cordova-plugman/pull/19
https://issues.apache.org/jira/browse/CB-4430#comment-13749605
2013/9/2 Shazron
> I believe your iCLA has been received. You are listed
We talked a bit about how frequent to release plugins / plugman / cli
during the hangout, but want to have a list discussion about it.
Some points to think about:
- It's convenient to be able to release at any time (get immediate feedback)
- Users may get annoyed if we update too frequently (updat
No go. I mean the command ran of course, but upon opening it up in my
browser, I got the same.
On 9/3/13 12:30 PM, "Gord Tanner" wrote:
>You will need to run:
>
>ripple emulate --path /path/to/cordova/project/platform/android/assets/www
>
>Let me know if that works for you.
>
>
>On Tue, Sep 3,
Neat.
Just tried it out:
$ npm version 3.1.0-0.8.0-dev
v3.1.0-0.8.0-dev
$ git tag -l
...
v3.1.0-0.8.0-dev
So, it's similar to what we have for other repos, except it adds a "v"
prefix. The prefix seems useful I think.
On Tue, Sep 3, 2013 at 1:14 PM, Braden Shepherdson wrote:
> Ooh, I didn't
I brought up this idea before (http://markmail.org/thread/75fv4ru7rd4vwrrb),
it was well received I think, but never made its way to our CuttingReleases
page. I'd like to move forward with formally introducing this concept on
our wiki page.
Component Lead:
- For each release, each repo has a Comp
+1 for #2 as well
On Tue, Sep 3, 2013 at 1:10 PM, Braden Shepherdson wrote:
> +1 for #2.
>
>
> On Tue, Sep 3, 2013 at 12:55 PM, Michal Mocny wrote:
>
> > +1 for option #2
> >
> >
> > On Tue, Sep 3, 2013 at 12:21 PM, Andrew Grieve
> > wrote:
> >
> > > For repos that use SemVer, there are two op
I like it - for clarity - I also think that the CLI and plugman should be
on the same day
On Tue, Sep 3, 2013 at 1:12 PM, Braden Shepherdson wrote:
> Agreed, I think this works.
>
> I share the hope that the frequency will drop. Though it looks again this
> year like the new iOS version is going
For Strategy page:
RE: Weekly Releases -- do we skip a release if there is nothing significant
to push, or do we release so long as there is at least one patch?
RE: Cadence Releases -- "These releases include: platform repos,
cordova-js, mobile-spec, cordova-docs, cordova-cli, cordova-plugman" --
Ooh, I didn't know about that command. I agree that it's a good way to
go... except that the wonky version numbers of the tools (3.0.0-0.10.2)
might make that impossible. Or is that valid semver?
On Tue, Sep 3, 2013 at 1:10 PM, Brian LeRoux wrote:
> we should encourage `npm version` as the meth
Agreed, I think this works.
I share the hope that the frequency will drop. Though it looks again this
year like the new iOS version is going to cause us some suffering.
Braden
On Tue, Sep 3, 2013 at 1:06 PM, Brian LeRoux wrote:
> Yup, agree w/ you both.
>
> I suspect we will see the releases
we should encourage `npm version` as the method to ensure things stay in
sync
(run `npm help version` to see what I'm talking about)
On Tue, Sep 3, 2013 at 10:00 AM, Michal Mocny wrote:
> If I understand correct, these tags aren't going to be used by npm, just
> make it easier for us to map np
+1 for #2.
On Tue, Sep 3, 2013 at 12:55 PM, Michal Mocny wrote:
> +1 for option #2
>
>
> On Tue, Sep 3, 2013 at 12:21 PM, Andrew Grieve
> wrote:
>
> > For repos that use SemVer, there are two options:
> >
> > 1. Update the version number at the time that the change is made
> > 2. Update the ve
Or you could create cordova-plugin-core, cordova-plugin-chromeos, and
cordova-plugin-phonegap repos, with a plugin.xml that have the dependencies
you describe to achieve the same result.
As the other guys mentoin, there's many ways to do this now without adding
a new feature which is the most prag
Tools release process looks good to me, but I've not done some parts of
that process before.
Braden
On Tue, Sep 3, 2013 at 12:54 PM, Michal Mocny wrote:
> For Strategy page:
>
> RE: Weekly Releases -- do we skip a release if there is nothing significant
> to push, or do we release so long as t
If I understand correct, these tags aren't going to be used by npm, just
make it easier for us to map npm releases to git hash's?
Sounds fine, but hoping these stay well lined up over time.
On Tue, Sep 3, 2013 at 12:33 PM, Andrew Grieve wrote:
> Right now CLI & plugman don't have git tags asso
Yup, agree w/ you both.
I suspect we will see the releases slow w/ time for both plugins and the
CI. (Hope, maybe?)
On Tue, Sep 3, 2013 at 9:57 AM, Michal Mocny wrote:
> I like it, but I would stress that this is "at most" once per week, not
> necessarily "every week". It should be fine to ju
I like it, but I would stress that this is "at most" once per week, not
necessarily "every week". It should be fine to just skip a week if nothing
interesting landed.
On Tue, Sep 3, 2013 at 12:30 PM, Andrew Grieve wrote:
> We talked a bit about how frequent to release plugins / plugman / cli
>
go for it, says I
On Tue, Sep 3, 2013 at 7:19 AM, Andrew Grieve wrote:
> Anyone opposed if I delete the old rc versions of docs
> (e.g. ite/public/docs/en/1.9.0rc1)
>
> They bloat the repo and I don't think add any value.
>
I don't see why we would ship anything other than the native platforms and
docs in an official Apache release.
We use those from the more frequently shipped CI, and plugins it just makes
good sense to stay on top of now that we have a semblance of dependency
management in Cordova.
On Tue, Sep
On Tue Sep 3 10:47 AM, Braden Shepherdson wrote:
> Agreed with Michal. There's actually a third option coming too: we want
> apps
> to be able to name dependencies. So you should be able to copy
> in the mobile-
> spec app, then `cordova plugin add` or whatever the
> syntax becomes, and it will
> i
It's been mentioned before, but with CLI, there's not a lot of utility in
doing official apache releases (uploading signed zips to dist.apache.org).
I don't think we should stop doing these entirely, but should we still do
these for each Cadence Release? An alternative would be to do them only
onc
+1 for option #2
On Tue, Sep 3, 2013 at 12:21 PM, Andrew Grieve wrote:
> For repos that use SemVer, there are two options:
>
> 1. Update the version number at the time that the change is made
> 2. Update the version number only when doing a release.
>
> Right now, #2 is what I've put in the wik
Wildshot: localhost:4400/ripple ?
On Tue, Sep 3, 2013 at 12:08 PM, Ray Camden wrote:
> Ok, forgive me if I did something stupid here.
>
> I cloned https://github.com/apache/incubator-ripple/tree/cordova-3.0. I
> did configure, jake, and then in Chrome I installed the unpacked
> extension. I ch
For repos that use SemVer, there are two options:
1. Update the version number at the time that the change is made
2. Update the version number only when doing a release.
Right now, #2 is what I've put in the wiki instructions, but it can be
changed of course :)
Two main reasons I think #2 will
Finally finished updating the wiki's instructions to follow this proposal.
Summary of changes:
https://wiki.apache.org/cordova/VersioningAndReleaseStrategy
- Explains our versioning strategy (SemVer vs CadVer)
https://wiki.apache.org/cordova/CommitterWorkflow
- Extracted Pull Requst Processi
Ok, I forgot to run cordova serve. I did, and then I get the same behavior
as before. A prompt and then infinite console.log messages.
On 9/2/13 8:32 PM, "Gord Tanner" wrote:
>Good news!
>
>I have a branch that is booting projects made with cordova 3.0 [1].
>
>It is basically a stripped down pla
Responses inline.
On Tue, Sep 3, 2013 at 11:07 AM, Jonathan Bond-Caron <
jbo...@gdesolutions.com> wrote:
> On Mon Sep 2 07:34 PM, Brian LeRoux wrote:
> > Here's a shot. Ideal flow tomorrow might be to generate a plugin called,
> lets say,
> > "Echo" that matches something we'd find in our docs,
Ok, forgive me if I did something stupid here.
I cloned https://github.com/apache/incubator-ripple/tree/cordova-3.0. I
did configure, jake, and then in Chrome I installed the unpacked
extension. I chose pkg/chrome.extension. Of the three folders I assume
that is the right one.
I then made a new p
For our purposes, CDVSplashScreen.m (as of 2.9.0) just needed a test for
the OS version when calculating the image bounds:
diff --git a/CordovaLib/Classes/CDVSplashScreen.m
b/CordovaLib/Classes/CDVSplashScreen.m
index fdb79fa..809ce35 100644
--- a/CordovaLib/Classes/CDVSplashScreen.m
+++ b/Cordova
On Mon Sep 2 07:34 PM, Brian LeRoux wrote:
> Here's a shot. Ideal flow tomorrow might be to generate a plugin called, lets
> say,
> "Echo" that matches something we'd find in our docs, automate add/remove
> with some sort of watch command. That way ppl are writing to the plugin spec
> from the beg
Agreed with Michal. There's actually a third option coming too: we want
apps to be able to name dependencies. So you should be able to copy in the
mobile-spec app, then `cordova plugin add` or whatever the syntax becomes,
and it will install all of the app's dependencies.
Braden
On Tue, Sep 3, 2
Anyone opposed if I delete the old rc versions of docs
(e.g. ite/public/docs/en/1.9.0rc1)
They bloat the repo and I don't think add any value.
I do like the idea of a `plugin watch` command, but I think we need to
consider a few points:
Our current plan for "plugin upgrade" is to plugin rm && plugin add. So,
we need an keep immutable copy of the original plugin as it was during
install time in order to uninstall correctly (thought: mayb
Just updated the README.md to remove the pre-3.0 setup instructions.
On Tue, Sep 3, 2013 at 9:53 AM, Michal Mocny wrote:
> I don't really think we need this feature:
>
> (1) We already have plugin's which support dependencies. Combined with the
> plugin repository, this means your alias featur
I don't really think we need this feature:
(1) We already have plugin's which support dependencies. Combined with the
plugin repository, this means your alias feature is equivalent to creating
a do-nothing plugin that specifies its dependencies.
(2) Also, we will soon have a way to specify appli
58 matches
Mail list logo
