incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian>
Subject Re: endless refactoring of plugins until "Cordova 2.x"
Date Wed, 28 Mar 2012 18:44:50 GMT
Lets face it: we're talking about renaming phonegap.js to cordova.js
and com.phonegap to org.apache.cordova ...which frankly was only bad
b/c we failed to document the change and give the community sufficient
warning. Since our actual method signatures aren't really changing
significantly maybe this will be easy.

Before we put this to a vote, I'd like to hear a precise description
of the methodology being proposed. Right now I envision 'huge merge
rebase hell' but maybe I'm making a mountain of a molehill.

On Wed, Mar 28, 2012 at 11:26 AM, Simon MacDonald
<> wrote:
> I added those tests to catch previous bugs like Cordova vs cordova and
> to catch any breakage to Plugins. Some recent changes made to common
> JS would have broken all existing plugins for 1.6.0.
> Simon Mac Donald
> On Wed, Mar 28, 2012 at 1:05 PM, Filip Maj <> wrote:
>> FYI one of Simon's latest commits to the mobile spec [1] added "platform
>> tests" for testing things such as the existence of the PhoneGap global and
>> other artifacts of the initial plugin work.
>> It looks like we are already on the way to documenting/testing that stuff,
>> so we are implicitly working towards a "document plugin mechanics" in 1.7
>> and beyond.
>> [1]
>> a=commit;h=79a84e59383501f1cccb025e64e35e31d284aac4
>> On 3/28/12 9:59 AM, "Patrick Mueller" <> wrote:
>>>On Wed, Mar 28, 2012 at 12:22, Brian LeRoux <> wrote:
>>>> What are we looking for as a resolution here? Commit that 1.7 we
>>>> document the plugin api?
>>>It's already defacto documented, in the code, and articles like Andy's.  I
>>>don't see the need to document something that in theory has a short
>>>My worry is that if want to continue to support folks who are living the
>>>bleeding edge of using 3rd party plugins or writing their own, or even
>>>reshipping the core runtime with tweaks, it's going to be hard to manage
>>>THAT and moving to 2.x in the same code stream.
>>>To me, separating the streams allows us to do 2.x work WITH NO REGARD TO
>>>1.x COMPATIBILITY.  Which seems like a huge win.  The downside is rebasing
>>>fixes for 1.x back into 2.x, but ... if the code is going to change so
>>>dramatically, how much change is there going to be there?
>>>Three words, and an explanatory movie: "total protonic reversal"
>>>Another alternative is to just tell people, WHO ARE USING 3rd PARTY
>>>PLUGINS: "look, we're doing breaking things is the 1.x stream, starting in
>>>1.5; if you need stability, you probably don't want to take our monthly
>>>releases".  It's hard to imagine how we realistically "document" this, and
>>>will in the end just cause more questions.
>>>Patrick Mueller

View raw message