On Wed, Jul 31, 2013 at 2:43 PM, Joe Bowser wrote:
> On Wed, Jul 31, 2013 at 11:22 AM, Andrew Grieve
> wrote:
> >>
> >> > That said, I'm still don't think that our mistake was anything other
> than
> >> > poor messaging / docs. 3.0 implies that breaking changes will happen.
> >>
> >> I disagree.
On Wed, Jul 31, 2013 at 11:22 AM, Andrew Grieve wrote:
>>
>> > That said, I'm still don't think that our mistake was anything other than
>> > poor messaging / docs. 3.0 implies that breaking changes will happen.
>>
>> I disagree. We should have kept the shim in so that people could
>> easily tran
On Wed, Jul 31, 2013 at 11:22 AM, Andrew Grieve wrote:
> My hope is that once we have a registry, and the registry can track which
> plugins work with which cordova versions, that it will help address this
> problem. E.g. you'll be told "org.apache.cordova.core.File v2.0 requires
> Cordova v3.2, y
On Wed, Jul 31, 2013 at 1:39 PM, Joe Bowser wrote:
> On Wed, Jul 31, 2013 at 8:32 AM, Andrew Grieve
> wrote:
> > Joe - please stop saying "I told you so". It really is counter-productive
> > and it takes away from having a feeling of shared responsibility for the
> > project.
>
> I completely di
On Wed, Jul 31, 2013 at 8:32 AM, Andrew Grieve wrote:
> Joe - please stop saying "I told you so". It really is counter-productive
> and it takes away from having a feeling of shared responsibility for the
> project.
I completely disagree. I explicitly disagreed with this because I was
afraid of
Joe - please stop saying "I told you so". It really is counter-productive
and it takes away from having a feeling of shared responsibility for the
project.
Checking in this change was not the only thing that brought us to this
point. Had we had the time to follow our release process, it would have
On Tue, Jul 30, 2013 at 3:51 PM, Don Coleman wrote:
> Is there a suggested way for plugins to support 2.9 and 3.0 with one code
> base?
>
Well, this is a good argument that I wish I had three weeks ago!
I think we should support the shim for this purpose, since we're still
supporting Cordova 2.9
Is there a suggested way for plugins to support 2.9 and 3.0 with one code
base?
Currently I'm adding org.apache.corodva.api.Dummy.java to my project and
using wildcard imports for org.apache.cordova.* and org.apache.cordova.api.*
Normally I wouldn't care about 2.9 but I'm trying to support PhoneG
Joe - I've not tried to be anonymous, and am planning on writing some blog
posts as well (now that we have a blog to post them on).
Fil - I'll spend some time tomorrow on #phonegap. That's a good suggestion.
Tommy - I agree with you about our deprecation policy. I think we should
discuss again ho
I dare you to idle in #phonegap on irc.freenode.net and answer every
plugin-related question.
On 7/30/13 12:33 PM, "Filip Maj" wrote:
>As for who is getting angry/confused, I am helping folk on #cordova IRC
>upgrade their plugins because it won't work / not accounted for in the
>upgrade guides.
As for who is getting angry/confused, I am helping folk on #cordova IRC
upgrade their plugins because it won't work / not accounted for in the
upgrade guides.
On 7/30/13 12:12 PM, "Tommy-Carlos Williams" wrote:
>I don't wanna sound like I am being a pain, but reallyŠ the whole
>deprecation polic
Honestly, I really wish that we broke this on 2.9 so that there was
enough time for people to get pissed off at PhoneGap Day. I feel that
those responsible got an easy ride since they work in mostly
anonymity, and it'll be public facing people like myself, Tommy and
Fil who feel the wrath of the u
Shazron,
As always, you rule..
Also, as an aside, how did I not know about this questions repo. Such a good
resource.
- tommy
On 30/07/2013, at 12:18 PM, Shazron wrote:
> I would - I'll see if I can write up a blog post later today based on my
> answer here: https://github.com/shazron/pho
I would - I'll see if I can write up a blog post later today based on my
answer here: https://github.com/shazron/phonegap-questions/issues/13
On Tue, Jul 30, 2013 at 12:12 PM, Tommy-Carlos Williams
wrote:
> I don't wanna sound like I am being a pain, but really… the whole
> deprecation policy
I don't wanna sound like I am being a pain, but really… the whole deprecation
policy thing is a bit pointless if it's not followed, and not noisy.
Most people who use plugins, use other people's plugins, they don't build them
themselves.
The use of plugins so far in the life of Cordova has been
Can I ask who's angry?
What would we put in a point release other than updating the docs? I
attempted a shim, but found that it was not that easy because .api.Foo
instanceof Foo, but Foo is not instanceof .api.Foo. Users need to update
all of their plugins for 3.0 anyways, and this has to be one o
Bah, this thread must have slipped my radar, apologies. I was replying to
the other one. Sigh.
On 7/30/13 11:57 AM, "Joe Bowser" wrote:
>So, yeah, remember how I fought this, and then suddenly we came to
>consensus because it's better to break everything all at once?
>
>https://issues.apache.org
So, yeah, remember how I fought this, and then suddenly we came to
consensus because it's better to break everything all at once?
https://issues.apache.org/jira/browse/CB-4454
Can we actually follow our deprecation policy from now on? There's
people there who are being unreasonable and asking for
Yup, break everything at once.
Simon Mac Donald
http://hi.im/simonmacdonald
On Wed, Jul 10, 2013 at 3:55 PM, Marcel Kinard wrote:
> Normally being very averse to changing pubic API's, I'm with Andrew and
> Ian on this. If we are going to be making breaking changes, especially if
> they are sm
Normally being very averse to changing pubic API's, I'm with Andrew and Ian on
this. If we are going to be making breaking changes, especially if they are
small, do them all at once.
On Jul 9, 2013, at 11:06 PM, Joe Bowser wrote:
> So far, we've asked plugin developers to migrate from the old-
Yeah, thats true, willingness to support plugins by original devs changes
with time. Its just inevitable.
I wonder if the solution here doesn't just end up being the plugin
universe? As maintenance is dropped, other willing devs have to take over
ownership via forks, and we update the references
On Wed, Jul 10, 2013 at 6:17 AM, Ian Clelland wrote:
>
>> Or worse, there will be the people who can't write Java at all and can't
>> manage to do a find/replace on it.
>
>
> For the record, I think I'm okay with stymieing the developers of native
> Java plugins for Cordova if they *can't write Ja
On Wed, Jul 10, 2013 at 9:17 AM, Ian Clelland wrote:
> On Tue, Jul 9, 2013 at 11:06 PM, Joe Bowser wrote:
>
>> If someone wants to be the face of these change in the community, I'm
>>
> OK with it. I just know that from last year, being the guy who broke
>> all the plugins in Cordova/PhoneGap i
On Tue, Jul 9, 2013 at 11:06 PM, Joe Bowser wrote:
> We're already going to have a heavy backlash from users who find that
> their old Cordova plugins that are using the old Plugin API that we
> had to shim in for 2.x are no longer going to work, this will
> literally be more salt on those wounds
Fair enough. We'll make a clean break and see what happens. I don't think
it'll be as bad as last year, that being said nothing could be worst than
how last year's major release went.
On Jul 9, 2013 8:30 PM, "Andrew Grieve" wrote:
> I agree with you that developers that want to use old plugins a
I agree with you that developers that want to use old plugins are going to
be annoyed that they won't work out-of-the-box with 3.0. You raise very
good points about big changes they'll need to do to update plugins (Plugin
-> CordovaPlugin & a plugin.xml file). If they manage to do this though, I
do
OK, so I'll put myself in the plugin developers shoes. (The ones that
work on shipping an app instead of working on cordova.)
So far, we've asked plugin developers to migrate from the old-style
plugins to CordovaPlugin so that their plugins will work with 3.0.0.
Many plugin developers have alread
I'de have to disagree with that argument, Joe. I think Andrew did the work
for core plugins, and there should be no published external plugins using
the new 3.0 plugin structure yet, right?
Are we intending to not break compatibility with some hypothetical external
plugin dev who used a pre-relea
This creates more work one week prior to release. If we didn't have a
deadline for this release, I'd be OK with it, but this means that the
trivial change would have to happen to all our plugins. Given the time
constraint, I think we shouldn't do it.
There's also the fact that our plugin develope
:) okay, now let's see if I can convince you Joe.
What I've done so far was put classes in o.a.c.api that extend the actual
implementations in o.a.c. This is a bit more annoying than I'd like,
because for it work properly, most types must continue to refer to the
o.a.c.api classes, or else you'll
Actually, on second thought, no, let's keep the compatibility classes
in for now. We may want to keep using this namespace post-3.0. I
think I misunderstood what was being asked.
On Tue, Jul 9, 2013 at 2:28 PM, Joe Bowser wrote:
> On Mon, Jul 8, 2013 at 12:50 PM, Andrew Grieve wrote:
>> Want t
On Mon, Jul 8, 2013 at 12:50 PM, Andrew Grieve wrote:
> Want to bring this up again.
>
> There was a bit of discussion on the bug:
> https://issues.apache.org/jira/browse/CB-4038
>
> I've already gone ahead with creating backward-compatiblity classes in the
> .api namespace, but I think it would b
I'm cool with that, as long as the import change is listed in the Upgrade guide.
On Jul 8, 2013, at 3:50 PM, Andrew Grieve wrote:
> Want to bring this up again.
>
> There was a bit of discussion on the bug:
> https://issues.apache.org/jira/browse/CB-4038
>
> I've already gone ahead with creati
Want to bring this up again.
There was a bit of discussion on the bug:
https://issues.apache.org/jira/browse/CB-4038
I've already gone ahead with creating backward-compatiblity classes in the
.api namespace, but I think it would be better to just delete them.
Main points in favour:
1. For 3.0, p
Okay, going to proceed then. resolveUri is a method I added yesterday in
the UriResolvers change, so no one's using it yet. I might be wrong, but I
see no way the change can break anything (knock on wood).
On Fri, Jun 28, 2013 at 5:13 PM, Joe Bowser wrote:
> Steve, Tim and Herm have been workin
Steve, Tim and Herm have been working on the 3.0 plugin breakout,
they've been combing through all the plugins on each of the platforms
and breaking them out. That being said, I haven't seen this method
used in 2.9.0, so I think we should be OK with this.
On Fri, Jun 28, 2013 at 1:35 PM, Andrew
Hey Joe,
Who are PBR guys?
What do you think might break?
On Fri, Jun 28, 2013 at 4:28 PM, Joe Bowser wrote:
> Actually, can the PBR guys look at this one? I'm pretty certain that
> this will break some plugin but now that they're broken out, I don't
> know which one.
>
> On Thu, Jun 27, 2013
Actually, can the PBR guys look at this one? I'm pretty certain that
this will break some plugin but now that they're broken out, I don't
know which one.
On Thu, Jun 27, 2013 at 7:45 PM, Andrew Grieve wrote:
> I just added UriResolvers, but needed to add a public method to
> PluginManager that re
I just added UriResolvers, but needed to add a public method to
PluginManager that really should be package-private. I'd like to fix this
since it seems easy to do. I've pushed up a branch showing this:
https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=commitdiff;h=f724df7101c300520b
July 19. In the past we've aimed at the last tues of every month.
On Tue, Jun 25, 2013 at 8:34 AM, Marcel Kinard wrote:
> Sounds like I missed something. What firm date?
>
> On Jun 24, 2013, at 2:04 PM, Joe Bowser wrote:
>
>> Unlike other releases, 3.0 is the only one with a firm date.
>
Sounds like I missed something. What firm date?
On Jun 24, 2013, at 2:04 PM, Joe Bowser wrote:
> Unlike other releases, 3.0 is the only one with a firm date.
+1 from me.
Simon Mac Donald
http://hi.im/simonmacdonald
On Mon, Jun 24, 2013 at 1:57 PM, Andrew Grieve wrote:
> Here's my thinking:
>
> - For 3.0, we're going to do a big push to ask devs to update their
> plugins, so we should put some effort into providing a clear set of
> supported APIs on t
Exactly. Unlike other releases, 3.0 is the only one with a firm date.
I don't feel that we have the time to refactor all the plugin
interfaces AND notify all our users. I think that this work will
heavily conflict with the plugin breakout stuff that we're currently
looking to merge back into Cor
Here's my thinking:
- For 3.0, we're going to do a big push to ask devs to update their
plugins, so we should put some effort into providing a clear set of
supported APIs on the Java side that they should code against.
- Right now we have a lot of public methods, and I think many of them are
only
I don't see any issue with this and it may help in 3.0 as we wouldn't
have to make as many methods public.
Simon Mac Donald
http://hi.im/simonmacdonald
On Mon, Jun 24, 2013 at 11:00 AM, Joe Bowser wrote:
> Can we do this post-3.0? This change seems a bit last minute.
> On Jun 24, 2013 7:57 AM,
Can we do this post-3.0? This change seems a bit last minute.
On Jun 24, 2013 7:57 AM, "Andrew Grieve" wrote:
> On the Java side of things, there are a few files in the
> org.apache.cordova.api namespace.
>
> I'd like to remove this namespace and put all Cordova classes under
> org.apache.cordova
On the Java side of things, there are a few files in the
org.apache.cordova.api namespace.
I'd like to remove this namespace and put all Cordova classes under
org.apache.cordova so that we can use package-private visibility where
appropriate.
For backwards compatibility, we can use the same trick
47 matches
Mail list logo
