incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <>
Subject Re: endless refactoring of plugins until "Cordova 2.x"
Date Wed, 28 Mar 2012 19:03:49 GMT
There is very little that we broke for plugins between 1.3 and 1.5/1.6.
The specific issue in terms of enabling plugin development in our past few
releases and breaking those in the next few releases are as follows:

- renaming phonegap.js to cordova.js
- removing certain plugin-specific methods on the PhoneGap global:
PhoneGap.addPlugin, PhoneGap.addResource, PhoneGap.hasResource from the
JS. Note: addResource / addPlugin are identical
- removing PhoneGap and window.plugins as globals

In 1.6 currently, we have added the above methods onto the cordova global
to enable backwards compat. Additionally we also drop the cordova global
onto the PhoneGap global to hopefully trip users up less.

We can create a clear migration path for users that used these methods
using the module system in cordova-js:

- cordova.define() for addPlugin/addResource
- try{cordova.require('mypluginid'); return true;}catch(e){return false;}
as replacement for hasResource

That is *it* (I THINK - please correct me if I'm wrong on this). Anything
else we develop moving forwards is completely new and users of previous
releases have no expectations about that.

I don't really see a need for two development streams if the above couple
points are the only implementation bits that are holding us back. Drop
deprecation notices for the above for all releases leading up to 2.0 and
remove them in 2.0. Blog + document the approach (e.g. Above code bits) to
migrate old methods listed above to new methods.

That's all I think is necessary unless I'm missing other APIs that plugin
authors used in pre-1.5 plugins.

On 3/28/12 11:52 AM, "Simon MacDonald" <> wrote:

>I don't see it being a huge merge issue. The way I envision it is that
>we stabilize the 1.X stream and continue to release every month but
>it's only going to be bug fixes.
>On the 2.0 stream, this is where we do the big architectural changes
>without fear of inconveniencing our users. The unfortunately part is
>that fixes in the 1.X stream will have to be ported to the 2.0 stream.
>Simon Mac Donald
>On Wed, Mar 28, 2012 at 2:44 PM, Brian LeRoux <> wrote:
>> 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
>>>> 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
>>>> so we are implicitly working towards a "document plugin mechanics" in
>>>> 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
>>>>>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
>>>>>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
>>>>>1.x COMPATIBILITY.  Which seems like a huge win.  The downside is
>>>>>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
>>>>>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