+1 ---but lets wait for Monday
as pat suggested I think we should package, and promote the dist too
> BTW: Once we're done whatever we need to do with 2.0, can we just increment
> by numbers if we're going by cadence? It'd clear up a lot of confusion.
Well, I'd personally like to keep MAJOR.MINO
Woah, hold up:
"The only downside is the dialog does not fully cover the screen."
Not in a spot to test this yet but how much is covered / how big is
the visual change?
If its at all different would we not want to deprecate the old
functionality and warn of the new behavior?
Final thought, perh
y with an ImageView in the background. I agree that our
>>> >splashscreen is janky, and needs to be fixed, but we should make it so
>>> >that
>>> >you can't tell it's a Cordova app.
>>> >
>>> >But yeah, I'm fine with this
+1
On Tue, Apr 24, 2012 at 3:31 PM, Filip Maj wrote:
> One thing I wanted to mention: I do not think it is necessary to have an
> "addplugin" api in JS.
>
> I think it should be completely up to the plugin author where and how they
> want to attach their JS API (if it exists) to global namespaces
On Wed, Apr 25, 2012 at 5:29 AM, Drew Walters wrote:
> I would agree that it shouldn't be "necessary" for the addPlugin API
> (more like addNamespace), however it was nice to have during my
> development. If you look at the addPlugin API you'll notice it waits
> until DOMContentLoaded is fired so
ss platforms.
>> >> >> >
>> >> >> > Would be a good exercise in plugin authoring, something that we
>> >>need
>> >> to
>> >> >> > work out details for for 2.0 anyways (but that's
Would like to know the exact offending piece of code too. I'd question
the need of even having that check its good to be defensive but
this code would just silently return instead of failing noisily
anyhow.
On Fri, Apr 27, 2012 at 11:29 AM, Jesse wrote:
> Channel.prototype.subscribe = functio
+1 to that; and, as a practice, we def should be failing noisily
rather than a silent return!
On Fri, Apr 27, 2012 at 12:05 PM, Filip Maj wrote:
>
>>My vote is typeof for everything but Array and Date, and add some
>>handy-dandy util methods isArray() and isDate() to do the checking with
>>the
>>
tag it, and create a branche for 1.8
On Mon, Apr 30, 2012 at 11:18 AM, Jesse wrote:
> +1 on readiness
>
> On Mon, Apr 30, 2012 at 11:13 AM, Anis KADRI wrote:
>
>> I am ready to tag my repos. I actually I'd like to do it today so that I
>> can tackle the 1.8.0 tasks.
>>
>> On Mon, Apr 30, 2012 at
I think mentor sign off is the last step?
On Wed, May 2, 2012 at 2:38 PM, Filip Maj wrote:
> With 1.7 and all the source headers in place for the docs, I think we can
> finally put together a legit Apache Release.
>
> What is our plan for this?
>
+1 Patricks thoughts as an immediate action.
* * *
Looks like the latest JS is roughly 120-180k. I would take this to
mean that the platform specific business tends to be around 60k
depending on the platform.
Would it be tenable to combine the JS into a single file that
platform/feature loads it
It's up for debate for sure.
http://www.mikealrogers.com/posts/nodemodules-in-git.html
Delete and add to dependencies in package.json for now.
On Thursday, May 3, 2012, Shazron wrote:
> I have no idea how node packages work, so I suppose, delete?
>
> On Thu, May 3, 2012 at 5:40 PM, > wrote:
yup it does in ./bin, also keep an eye here:
https://issues.apache.org/jira/browse/CB-630
On Fri, May 4, 2012 at 4:13 AM, Jan Becicka wrote:
> Hm, it looks like iOS does not have such tools… Or did I miss something?
> Regards,
> Jan
>
>
>> Every platform has its own set of CLI tools at the momen
// i'd like something like this...
require('cordova').platform(function(platform) {
console.log(platform.name) // Tizen <---don't laugh, its gonna happen!
console.log(platform.version) // '0.7.0'
// gratuitous...
console.log(platform.version.MAJOR // 7
console.log(platform.ver
>
> On Tue, May 8, 2012 at 2:17 AM, Brian LeRoux wrote:
>> // i'd like something like this...
>> require('cordova').platform(function(platform) {
>>
>> console.log(platform.name) // Tizen <---don't laugh, its gonna happen!
>> console
> Do we really need to make this async?
no, no. thought we'd normally stay away from sync calls to the native
bridge if we could. perf wise. etc.
> The only upside to async is that we
> can request the information lazily.
oh, well I disagree here too! but lets save that for another day, like ne
wait, so we're going to echo the version of the widget in config.xml
but *not* expose the runtime version? or am I reading things wrong?
On Tue, May 8, 2012 at 6:57 PM, Filip Maj wrote:
> +1 window.widget
>
ok cool, eh so where does config.xml live in an android proj anyhow?
or any platform for that matter? inside the www?
(happy we are officially going to start supporting it. still think we
should re-think the device object and the baggage it contains into
something else.)
should this be something
ya thats fun =)
On Mon, May 7, 2012 at 8:33 PM, Filip Maj wrote:
> Nic. Just npm-install'ed that, me likey.
>
> Thanks Pat!
>
> On 5/4/12 9:51 AM, "Patrick Mueller" wrote:
>
>>I posted a little YouTube video yesterday showing how I do development on
>>cordova-js:
>>
>> http://www.youtube.
Probably the svn repo for the website src?
On May 10, 2012 1:34 AM, "Shazron" wrote:
> I'm going to include the PSDs in the repo. They are 54MB though, and
> I'm wondering if there's a better place for it besides the iOS repo.
>
>
> On Thu, May 3, 2012 at 1:51 PM, Shazron wrote:
> > Do I just in
Ah np, the download currently includes no cli tooling. Just the bare
bones there. You need the dev repos to get the tools. This will change
in the future though how is yet to be sussed out.
On Thu, May 10, 2012 at 1:49 PM, Jan Becicka wrote:
> I'm sorry, I feel stupid…
> I simply don't see it. I
committed it; now waiting for the svnweb thing to do its thing
On Fri, May 11, 2012 at 7:34 PM, Filip Maj wrote:
> Basically can we put a link to http://callback.markmail.org/search/?q= on
> the website?
>
d_mbox/incubator-callback-dev/
>
> On Sun, May 13, 2012 at 11:04 PM, Brian LeRoux wrote:
>> committed it; now waiting for the svnweb thing to do its thing
>>
>> On Fri, May 11, 2012 at 7:34 PM, Filip Maj wrote:
>>> Basically can we put a link to http://callback.markmail.org/search/?q= on
>>> the website?
>>>
yup. both would be super helpful. I can open up the tickets. you guys
feel there is time enough for 1.8 to do this?
On Mon, May 14, 2012 at 6:57 PM, Jesse MacFadyen
wrote:
> +1 to doing both.
> This applies to WP7 as well.
>
> Cheers,
> Jesse
>
> Sent from my iPhone5
>
> On 2012-05-14, at 9:46 A
Good times. You guys want to try and get the Air repo up before
graduation or wait until after too?
On Tue, May 15, 2012 at 12:43 AM, Michael Brooks
wrote:
> Right.
>
> And just to simplify the transition, we would rather not immediately rename
> "incubator-cordova-blackberry-webworks" to
> "incu
how ya guys feeling on 1.8?
ship the code we have in that branch or defer. If we defer, we
> need to start working on other fixes asap so we have something to show for
> this release on Android.
> On May 15, 2012 9:55 PM, "Brian LeRoux" wrote:
>
>> how ya guys feeling on 1.8?
>>
anada, not sure if that matters.
>> >
>> > On Wed, May 16, 2012 at 10:40 AM, Filip Maj wrote:
>> >
>> >> I'm fine with it. Friendly observation that there are still a _ton_ of
>> >> issues slated for 1.8 to be resolved. We're less than
> 1. The iOS version of 'debug' seem to be able to build any project via
> args, is this a requirement?
no, onlly to the project that it is local is better also
> 2. For WP7 I have had to write a command line application in order to
> install and launch the app on a device or emulator, should th
Can we back up a little to the orig proposal. Why not walk the DOM w/
cordova.js and add a URL param on hrefs with a target _blank for iOS to
look for?? Let's keep Cordova as close as possible to browsers where we
can. This isn't to say a programmatic API isn't needed but duck punching
window.open
Agree we could use both those thins but before we solve w/ a new
nonstandard api: what doesn't work about target _blank again?
On Fri, May 18, 2012 at 7:32 PM, Andrew Lunny wrote:
> Yes, a cross-platform loadUrl with some tweaks would be the right fix. The
> catch I remember with loadUrl on Andro
> * not cross-platform, and will never work on Android 2
why not?
> * doesn't really work on iOS - iOS can't access the value of the target
> attribute, so it's just checking whether "target" is set. Shaz has more
> details in the JIRA issue referenced above
could we not walk the dom in the cord
>> won't work with how iOS handles this.
>>
>> Android has this undocumented API which we need to document anyway,
>> all we need is iOS to support it.
>>
>> +1 for loadUrl as spec'ed already by Android.
>>
>> Shaz
>>
>> On Fri, May 18,
Thats good news. How do we get access to / provision machines?
On Sat, May 19, 2012 at 1:13 AM, Filip Maj wrote:
> Talked to some dudes in #asfinfra on irc; they don't see a problem with us
> hosting testing stuff outside of apache infra. Werd.
>
> On 5/18/12 4:06 PM, "Filip Maj" wrote:
>
>>Hi l
Sorry shaz, I must be dense but I missed the technical reasons?
On May 19, 2012 11:48 AM, "Shazron" wrote:
> > The method I'm proposing
> > assumes all link events are trapped, inspected for a url param, and in
> > its absence, falls back to default behavior. Maybe thats not
> > realistic. Seems
s back up (it's under maintenance right now), see my
> first/second comment on this issue:
> https://issues.apache.org/jira/browse/CB-362
>
> It's a bit too long to rehash :)
>
> On Sat, May 19, 2012 at 8:17 AM, Brian LeRoux wrote:
>> Sorry shaz, I must be dense but
s and adding my recommendation in a while
> ...
> >
> >
> >
> > On Sat, May 19, 2012 at 7:43 PM, Shazron wrote:
> >
> >> No. Read it again, especially the two request part. For urls NOT in
> >> the whitelist, the first request will be rejected by the
Also, pls consider the solution I propose comes with the benefit that links
continue to work in the browser without modification.
On May 20, 2012 9:43 AM, "Brian LeRoux" wrote:
> How is opening a URL in a web browser a security risk to the Cordova code
> shaz?
>
> Jesse:
How do you guys feel about retiring the various first run projects for
a single one that we 'vendor' into each ala cordovajs? I kinda prefer
that experience be like the iOS one.
t idea. Why don't we use the example project that Libby sent a pull
>> request on awhile back. It exercises all of the API and looks a mite bit
>> better than the current one we are using.
>>
>> Simon
>>
>> On Tuesday, May 22, 2012, Brian LeRoux wrote:
>&
ooh, that does look nice! a little nervous we're going to be
inheriting some strong maintenance w/ something like this but it is
pretty cool
On Tue, May 22, 2012 at 4:41 PM, Drew Walters wrote:
> Took a couple of screen captures of Libby's sample project for those
> that haven't built/run it:
>
>
+1
its not a standardized api anyhow / its def a phonegap plugin of the future
On Fri, May 25, 2012 at 2:58 PM, Simon MacDonald
wrote:
> If we are getting rejections in the App store I think we should fix it
> immediately. I'd be happy to test it for Android as I don't expect it will
> require a
>> > > I would like to see the sample app at least show listening for the
>> > > 'deviceready' event since that seems to be a common problem and
>> > > provides some guarantee of Cordova initialization.
>> > >
>> > > Something like this maybe?
I remember a thread but cannot find it where we discussed this. I
opened a ticket at infra. They need a thread that shows there is rough
consensus. Basically the idea is a repo where we can put odds and ends
like scripts, our hello world, whatever.
Thoughts?
Sounds good to me.
On Tue, May 29, 2012 at 3:18 PM, Joe Bowser wrote:
> Hey
>
> Is it cool if for the 1.9 release, we merged the CordovaWebView source into
> the master once 1.8 is tagged? It'd be good to get this done early to make
> sure that this makes it in for the release candidates. The l
Hi Dominik, I had a quick look around and there is prior art here (in
opera anyhow) [1] so I think tis a good addition. We've slated to have
a second look at media post 2.x in the roadmap so I updated it there.
[2]
1. http://dev.opera.com/articles/view/html5-audio-radio-player/
2. http://wiki.apac
precisely the sort of thing we wanna do and likely quite doable by 2.x
+1
On Wed, May 30, 2012 at 10:43 PM, Shazron wrote:
> Generally +1 on XHR2, but we're still planning on supporting iOS 4.2 in
> Cordova 2.0, so we'll need to shim if not available.
>
> On Wed, May 30, 2012 at 9:39 PM, Dave Jo
For future reference, so I don't have search markmail, I started a
wiki page w/ this here. Thx for figuring that out Fil
http://wiki.apache.org/cordova/UpdatingIncubationStatusPage
On Wed, May 30, 2012 at 12:15 PM, Filip Maj wrote:
> Phew, updated that page! That was not easy.
>
> http://incubato
gt; we based the apis on have had a few revisions and it's worth going through
> them. Battery, media, accelerometer/compass vs deviceorientation vs
> devicemotion, contacts, etc etc!
>
> On 5/31/12 5:47 AM, "Brian LeRoux" wrote:
>
>>Hi Dominik, I had a quick l
given the backwards compat and the fact that 2.x is really only a
couple of months out maybe hold off until we do 3.x planning even
On Thu, May 31, 2012 at 10:06 AM, Filip Maj wrote:
> How about a compromise: slate use of XHR2 as the way to do it for 2.0 or
> 2.x (documentation issue) and then fi
love everything except the echo stuff; could we add a quiet flag? only
want noise if something breaks
On Thu, May 31, 2012 at 12:39 PM, Anis KADRI wrote:
> Hi guys,
>
> I did not want to mess with the current client tools for Android so I
> created a new create script and called it create2.
>
> T
;)
> I can definitely add a "-v" flag and make sure that the messages display
> only if that option is passed.
>
> On Thu, May 31, 2012 at 1:40 PM, Brian LeRoux wrote:
>
>> love everything except the echo stuff; could we add a quiet flag? only
>> want noise if some
Hey Sebastian, for the moment the CLI business is just plain Bash
(most portable situation) and only for very narrow use case of project
generation. Anis is going to be tackling plugin installation based on
prior art by Andrew Lunny but this is a long term thing not so much
something we can just do
er then anyhow.
>
> -d
>
> On Thu, May 31, 2012 at 10:19 AM, Brian LeRoux wrote:
>> given the backwards compat and the fact that 2.x is really only a
>> couple of months out maybe hold off until we do 3.x planning even
>>
>> On Thu, May 31, 2012 at 10:06 AM, Filip
Should def use JSON.parse ...tho generally no religious exceptions to eval
or cousins like new Function. Super handy constructs for some purposes like
dynamic function generation. Used em a lot in Lawnchair.
On Friday, June 1, 2012, Patrick Mueller wrote:
> On Fri, Jun 1, 2012 at 8:19 PM, Jesse
> CB-597 + CB-563, CB-179,
lets punt to 1.9 and start a thread discussing webos future
> Other than that I think tagging 1.8 this week should be done ASAP.
yes
quick update that we now have a repo for the random (like the starter project)
thank you jukka!!
Hey guys, I'd like to start some discussion about where we put our
efforts and how.
Currently the webOS and Bada platforms collectively account for
<20million devices globally and dropping. I don't think we should
outright remove our support but I am thinking we do drop them from the
official dist
gt;
> On Mon, Jun 4, 2012 at 2:18 PM, Brian LeRoux wrote:
>>
>> Hey guys, I'd like to start some discussion about where we put our
>> efforts and how.
>>
>> Currently the webOS and Bada platforms collectively account for
>> <20million devices globa
Created a quick wiki article for this:
http://wiki.apache.org/cordova/PlatformSupport
On Mon, Jun 4, 2012 at 2:38 PM, Brian LeRoux wrote:
> thats interesting, how would that be maintained...just an old branch I guess?
>
> On Mon, Jun 4, 2012 at 2:22 PM, Shazron wrote:
>> I th
un 4, 2012 at 2:53 PM, Jesse wrote:
> so maybe we need to add LateMorning, MidAfternoon, 2MinutesToMidnight, ...
>
> On Mon, Jun 4, 2012 at 2:50 PM, Shazron wrote:
>
>> If anyone wants to maintain, it would be off 1.9.0 and branched, yup
>>
>> On Mon, Jun
license header in a generated project isn't a big deal; at that moment
the developer whom generated it can choose to relicense (or not) as
they wish
On Mon, Jun 4, 2012 at 5:54 PM, Filip Maj wrote:
> I don't see the issue here.
>
> The example code we ship is apache-owned, so the license header
Today we have Getting Started guides which walk the developer through
the right buttons to click in their IDE. Soon we will have most of the
plumbing cleaned up for the CLI so I'm thinking we have a second set
of getting started guides but focused on CLI usage only.
Thoughts?
Just had a water cooler discussion about the holy grail of having one
js file to rule them all.
1. platforms have differences but could it be feasible to ship all
those differences in the single file and sort out which traits to load
at runtime. this would certainly introduce a latency and parse h
<3
also get Anis to send a pull req for the new create script love.
sooner that stuff is in the better.
On Wed, Jun 6, 2012 at 2:52 PM, Joe Bowser wrote:
> Hey
>
> So far 1.8.0 has been out for a day, and nothing has imploded yet. So, I'm
> going to do the rebase and get CordovaWebView merged w
this is getting meta. maybe we should make it transport agnostic so
that ppl could use json or yaml.
/me ducks
(In seriousness having one xml file for this business would make good sense.)
On Thu, Jun 7, 2012 at 11:35 AM, Dave Johnson wrote:
> Speaking of which, we should probably merge plugins
If we're going to break stuff 2.x is the time.
On Thu, Jun 7, 2012 at 11:57 AM, Shazron wrote:
> Not sure if we agreed or there was a consensus on having one xml file
> to rule them all, and the timeline. If so, jira issues should be
> created
>
> On Thu, Jun 7, 2012 at 11
Is done (pls verify/hack up as needed).
http://wiki.apache.org/incubator/June2012
(I've been keeping a log of all the things as they happen / just
forgot to publish it.)
On Fri, Jun 8, 2012 at 6:14 AM, Jukka Zitting wrote:
> Hi,
>
> On Mon, Jun 4, 2012 at 4:11 AM, Marvin wrote:
>> The board me
>From a policy point of view I think we should just issue point
releases on the src but not go through cutting an entire release.
(Unless its a security fix which we should issue general release and
make a big hoo hah about it.)
On Mon, Jun 11, 2012 at 11:29 AM, Shazron wrote:
> I doubt it's *our
So we have a fairly big issue in iOS 1.8 wherein a PhoneGap app is
crashing if the user swipes down the notification centre while in-app.
The question is whether this is a bug big enough to cut an 1.8.1
official release for all platforms or if pointing users to the minor
tag is enough.
[+1] releas
anged, but still
> considerably easier than the tag->domino effect we have now. IMO
>
> On Mon, Jun 11, 2012 at 2:18 PM, Filip Maj wrote:
>
>> +1 release 1.8.1
>>
>> On 6/11/12 2:15 PM, "Brian LeRoux" wrote:
>>
>> >So we have a fairly big
ould break stuff for the 2.0 release so it will be
>>>consistent going forward.
>>>
>>>Simon Mac Donald
>>>http://hi.im/simonmacdonald
>>>
>>>
>>>On Thu, Jun 7, 2012 at 3:14 PM, Brian LeRoux wrote:
>>>> If we're going to
solution!
On Mon, Jun 11, 2012 at 3:29 PM, Shazron wrote:
> To build in support now? I like Patrick's suggestion of adding a
> "+LoadAtStart" to the plugin identifier, it is least intrusive.
>
> On Mon, Jun 11, 2012 at 3:23 PM, Brian LeRoux wrote:
>> how much effort w
t;>
>> > >> On 6/11/12 2:30 PM, "Jesse" wrote:
>> > >>
>> > >> >Before I tip my hand on a vote ...
>> > >> >Is there any chance of a middle ground here?
>> > >> >Updating all platforms to 1.8.1 for the benefit of
;> > >> Would love to hear what non-Adobe folks have to say about this.
>> > >>
>> > >> On 6/11/12 2:30 PM, "Jesse" wrote:
>> > >>
>> > >> >Before I tip my hand on a vote ...
>> > >> >Is there any chance
n, Jun 11, 2012 at 3:45 PM, Brian LeRoux wrote:
>
>> I'd like to propose we take jesses suggestion but with the tweak that
>> we do not add a new patch level. The downstream distribution would
>> just read:
>>
>> phonegap-1.8.x.zip
>>
>> wherein th
ship
>> phonegap-1.8.1.zip (just simpler).
>>
>> On Mon, Jun 11, 2012 at 3:58 PM, Brian LeRoux wrote:
>>
>> > Well, here's the proposal again.
>> >
>> > 1. We ship a package and it is titled phonegap-1.8.x.zip
>> > 2. Inside that pack
un 11, 2012 at 3:44 PM, Brian LeRoux wrote:
>> Well, ok --- so the idea of config.xml support is that it adheres to
>> the proj goal of being standards based impl for web tech. There is
>> much debate of the perfection of various manifests (and even debatable
>> there
We have a proliferation of manifest-like files that are, mostly, XML.
iOS
- [APP_NAME]-Info.plist
- Cordova.plist
Android
- plugins.xml
- cordova.xml
BlackBerry
- config.xml <---yay
- plugins.xml <---wait, wat
WindowsPhone
- ?
Bada
- config.xml <--- yay
* * *
I created a parent issue [1] to r
guess its time we stopped shipping the prebuilt and start looking at
shipping the src / compile. this will fix our 'permissions for all the
things' in android land too
On Tue, Jun 12, 2012 at 1:54 AM, Shazron wrote:
> May or may not be related to this issue:
> https://issues.apache.org/jira/brows
+1
On Tue, Jun 12, 2012 at 2:20 PM, Shazron wrote:
> If it's a breaking change, I'd like it for 2.0
>
> On Tue, Jun 12, 2012 at 1:40 PM, Filip Maj wrote:
>> Yay/nay for orientation? Punt it to post-2.0 ?
>>
>> On 6/11/12 4:56 PM, "Shazron" wrote:
>>
>>>More links:
>>>1. http://wiki.apache.org/c
> Config.xml introduces redundancy in terms of specifying app metadata in
> some cases. How are we going to consolidate the two places where some app
> info can be specified?
It does, my ideal situation is the canonical src is the config.xml and
the native bits are build artifacts (detritus, maybe
> Once we ship 2.0 we need a revision of _all_ APIs pretty badly. Lots of
> specs have been updated/revised. Review the mobile landscape. See what
> direction/specs the functionalities we aim to provide with cordova are
> going and polyfill those for our users.
This is true. The sys-apps group in
our own
> FileTransfer. Pretty much all of them haha.
>
> On 6/12/12 3:44 PM, "Brian LeRoux" wrote:
>
>>> Once we ship 2.0 we need a revision of _all_ APIs pretty badly. Lots of
>>> specs have been updated/revised. Review the mobile landscape. See what
>>
Makes great sense --- would love to have the ability for any platform
to use a server/proxy reporter. You could imagine this infra being
useful in dev time, and production time, for general logging/crash
reporting.
On Wed, Jun 13, 2012 at 10:02 AM, Filip Maj wrote:
> Hey all,
>
> Trying to fill i
Agree for removing from distribution. Would like to propose we only ship:
- iOS
- Android
- BlackBerry
- Windows Phone
- Bada
...for the moment.
On Wed, Jun 13, 2012 at 3:59 PM, Anis KADRI wrote:
> I say we leave it dormant until open webos 1.0 is released in September or
> until HP decides to
do eet
On Mon, Jun 18, 2012 at 2:46 PM, Filip Maj wrote:
> +1
>
> On 6/18/12 11:42 AM, "Joe Bowser" wrote:
>
>>Hey
>>
>>I created the buttons branch for work on button binding. I'm thinking we
>>should do work with buttons in that branch. As for the other branch, the
>>old CordovaWebView branc
I'm of the opinion that native impl should *not* abstract the
platforms at the plugin level. It breaks old plugins, which is fine,
but for what benefit? Conceptual purity at that level will make it
harder to recruit plugin authors from their respective navtive
platforms.
On Mon, Jun 18, 2012 at 3:
: get this change in for 1.9, deprecate the
> .ctx member in 1.9 as well, and axe it in 2.0.
>
> On 6/18/12 12:15 PM, "Brian LeRoux" wrote:
>
>>I'm of the opinion that native impl should *not* abstract the
>>platforms at the plugin level. It breaks old plugins, whi
tx a Context like what the convention is,
> we should conform to convention and call the CordovaInterface something
> descriptive like cordova since that will be less disruptive.
>
> So, yes, we've been kicking this can around the parking lot for a while.
>
> On Mon, Jun 18, 2012 at
aight
On Mon, Jun 18, 2012 at 6:13 PM, Filip Maj wrote:
> New thread methinks.
>
> On 6/18/12 3:06 PM, "Brian LeRoux" wrote:
>
>>ok, that makes sense! it isn't even a Context. ya, bad. kill. with. fire.
>>
>>(and a deprecation notice)
>>
>&
We don't really have one tho I think we loosely follow Semantic
Versioning. In Android-land we recently merged in CordovaView which
has an API change which will break many plugins. In Semantic
Versioning reality we are completely justified to kill an API in 2.x
which would make a great deal of pai
Fantastic! I've opened an issue w/ infra to create
incubator-cordova-tizen git repo. [1] Shouldn't take very long. Is
there a way for us to have a look at the src in advance?
[1] https://issues.apache.org/jira/browse/INFRA-4935
On Tue, Jun 19, 2012 at 5:59 AM, Paul Plaquette
wrote:
> Hi folks,
> What are the implications of UUID for Android, BB, and any others
> (platform policy wise)? I see a WP7 quirk in the docs already.
> Do we NEED this?
That is the key question. I'd say that is the app developer concern
(generating a guid from js and putting in localStorage is pretty
easy).
agree---most important focus will be getting our plugin api docs and
tools in order
On Mon, Jun 18, 2012 at 7:54 PM, Shazron wrote:
> +1
>
> On Mon, Jun 18, 2012 at 4:47 PM, Filip Maj wrote:
>> Our homebrew Media API is likely getting scrapped after 2.0 right? If so
>> refactoring it is not wort
wow, I really like the issue tracker (and gui in general actually).
problem is we're just starting to get our groove here and fear another
change would really tick off the community!
cool proj tho.
On Tue, Jun 19, 2012 at 9:02 AM, Ross Gardler
wrote:
> I just wanted to flag a new Incubator propo
had it been an option at the time of our incubation I suspect we
would've gone for this system for sure
On Tue, Jun 19, 2012 at 9:34 AM, Ross Gardler
wrote:
> On 19 June 2012 14:19, Brian LeRoux wrote:
>> wow, I really like the issue tracker (and gui in general actually).
>&
the standard deprecation techniques for the native platforms
>> enough ahead of time, blog about upcoming breaking changes, provide
>> tutorials and documentation for how to migrate, I am fine with it.
>>
>> On 6/18/12 3:25 PM, "Brian LeRoux" wrote:
>>
>>&g
> ...the more things we simply offload to call 'app
> developer concerns' the less anyone will need our framework. IMHO this
> would be pursuing the 'cease to exist' mantra from the wrong direction.
how so? should we be advocating adding a unique identifier to web
browser apis? (don't think it'll
create a new account), just like Github's system.
>>
>> My fork of Allura has been stuck at "analyzing" (in the left sidebar)
>> for a while and I can't find where to send a merge request yet in the
>> UI from my forked repo, so I can't evaluate
1 - 100 of 657 matches
Mail list logo
