You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Patrick Mueller <pm...@gmail.com> on 2012/03/26 16:00:35 UTC
endless refactoring of plugins until "Cordova 2.x"
see:
https://issues.apache.org/jira/browse/CB-298
"DEPRECATE and then remove "plugins" and "PhoneGap" global objects from
JavaScript implementation"
So, at this point, it looks like anyone with plugins who wants to follow
the Cordova releases will be in a constant state of refactoring to
accommodate each new point release. That is so painful.
Add to this, our release cycle is 4 weeks, so we realistically have a
couple of weeks to implement refactorings, such as described in the
referenced bug. Which means we don't have a lot of time to capture
feedback from those refactorings before they become "new API".
This really isn't great.
I think at this point, I'd like to freeze the 1.x "API", and have a
separate stream of development for 2.x.
Downside:
- separate streams of development
Upside:
- easier to stabilize 1.x level API
- longer-lived streams of development for 2.x
- most folks will only have to refactor their plugins once, from 1.x to
2.0, instead of 1.5 -> 1.6, 1.6 -> 1.7, ...
--
Patrick Mueller
http://muellerware.org
Re: endless refactoring of plugins until "Cordova 2.x"
Posted by Filip Maj <fi...@adobe.com>.
http://wiki.apache.org/cordova/RoadmapProjects
This wiki article needs some updating, possibly splitting it up into
separate pages. A separate article for the plugin target might be a good
idea.
On 3/26/12 11:43 AM, "Brian LeRoux" <b...@brian.io> wrote:
>I'm far more in favor of shims that barf deprecation notices than
>maintaining two branches.
>
>Bryce/Patrick: I'll kick up a separate thread about roadmapping plugin
>stuff.
>
>
>On Mon, Mar 26, 2012 at 11:31 AM, Shazron <sh...@gmail.com> wrote:
>> I haven't done any JavaScript shims but I've eased the pain for users
>> needing to use plugins by adding compatibility headers for all the
>> PhoneGap/Cordova versions out there (0.96 to 1.5.0). See my plugin in
>> this issue and its README:
>> https://issues.apache.org/jira/browse/CB-330
>>
>> These compat. headers I include in CordovaLib but is so far
>> undocumented. What the procedure is, you would write a plugin meant
>> for 1.6.0 (ie the latest version), and for older version support, a
>> dev would included the appropriate compatibility headers.
>>
>> It's working great so far for the CDVLocalStorage plugin - from the
>> same plugin code base (one .m and .h) through the compat. headers,
>> everything just works with older versions as well. I assume we can do
>> something similar for JavaScript as well (shims).
>>
>> Shaz
>>
>> On Mon, Mar 26, 2012 at 11:15 AM, Bryce Curtis <cu...@gmail.com>
>>wrote:
>>> I agree that there's no way to know what plugins will look like in 2.x.
>>> Until then, I strongly believe we need to maintain the same
>>>(undocumented)
>>> API that plugins currently rely upon, with the goal that 3rd party
>>>plugins
>>> won't need to be updated again until 2.x - They already took a hit with
>>> renaming in 1.5.
>>>
>>> Regarding the plugin APIs (JS & native), we can't identify with
>>>certainty
>>> which ones will be deprecated until we are further along with the 2.x
>>> plugin architecture, so we shouldn't confuse users until details are
>>>worked
>>> out and prototypes running. Regarding API stability, while we have
>>> discussed deprecating methods like addConstructor, window.plugins,
>>>etc.,
>>> the fact that they have remained consistent for many releases (well
>>>over a
>>> year or 2) has led to their wide use.
>>>
>>> After 1.6.0 release, we should schedule a plugin meeting to go over the
>>> priorities, what's been done to date, and where it's going.
>>>
>>> On Mon, Mar 26, 2012 at 1:05 PM, Filip Maj <fi...@adobe.com> wrote:
>>>
>>>> Thanks Brian, I was just going to respond saying the same thing but
>>>>you
>>>> beat me to it!
>>>>
>>>> >What I'm trying to say is that I'm not at all inclined to +1/-1 until
>>>> >we have agreed on the particulars of the change we seek.
>>>>
>>>> ^^ The above is the underlying issue. I suggest we do that as a first
>>>>step.
>>>>
>>>> The referenced bug in this thread is just a small part of the overall
>>>> work. Side note: deprecating + removing the "PhoneGap" JS global is
>>>>not
>>>> necessarily for plugins, it's a part of the Apache rename. The only
>>>> changing part of the bug is removal of window.plugins. I prototyped a
>>>> deprecation approach in a branch here (diff view):
>>>>
>>>>https://github.com/filmaj/incubator-cordova-js/compare/masterŠdeprecati
>>>>on
>>>>
>>>> Re: addResource/hasResource. These do not exist in cordova-js right
>>>>now.
>>>> They are effectively gone. They were only there for BB + Android
>>>>anyways.
>>>> I had one dude on IRC complain that we removed that in 1.5.0 without
>>>>first
>>>> deprecating. No huge outcry. Not saying that the fact we just axed it
>>>>is
>>>> good - it wasn't. We should have deprecated first, no doubt. My point
>>>> about these two specific methods is, it already happened last
>>>>release, so
>>>> it is a moot point to discuss.
>>>>
>>>> Additionally we have had some work done to try to prototype what a
>>>>final
>>>> plugins-based approach to app development would look like,
>>>>specifically
>>>> Andrew Lunny's "pluginstall" work (which I believe started from a
>>>> thread/discussion that happened on the list between Andrew and Pat).
>>>>Here:
>>>> https://github.com/alunny/pluginstall
>>>>
>>>> Andrew is most of the way there in terms of defining an XML file
>>>> describing the integration of native source for a plugin, see:
>>>>
>>>>https://github.com/alunny/pluginstall/blob/master/test/plugin/plugin.xm
>>>>l
>>>>
>>>> The native plugin architecture has been around for a while. It is
>>>>stable.
>>>> Not much needs to be done there.
>>>>
>>>> The biggest question in my mind is how we want to handle the
>>>>JavaScript.
>>>> With cordova-js already implementing a basic module system with a
>>>>hard API
>>>> for the exec() function, we're actually not too far away.
>>>>
>>>> We should keep going in enumerating all these things that make up the
>>>> plugin goal in this thread and drop whatever else comes up into a wiki
>>>> page.
>>>>
>>>> It seems like it is a "safer" idea to slate all the plugin changes /
>>>>API
>>>> removals for 2.0. That being said, can we agree to drop deprecation
>>>> notices into the agreed-upon APIs that will be axed leading up to 2.0?
>>>>
>>>> > I think we
>>>> >can agree on the spirit of the focus of the work being a world of
>>>> >plugins and tooling for automation. We haven't added much outside of
>>>> >battery (and a new platform).
>>>> >
>>>> >1. The plugin architecture remains completely undocumented.
>>>> >2. We do not support 3rd party plugins.
>>>> >3. There is no automation or tooling.
>>>> >
>>>> >Are plugins from an API standpoint stable today? (I'm guessing not
>>>> >when I think of things like addConstructor.)
>>>> >
>>>> >If they aren't stable, undocumented, unsupported by our effort, and a
>>>> >work in progress for tooling: why are we concerned with breaking
>>>>them?
>>>> >
>>>> >(Take all above with grain of salt, I think having a 2.x branch a
>>>>good
>>>> >idea, but will slow us down for no direct benefit to Cordova that I
>>>> >can currently see.)
>>>>
>>>>
Re: endless refactoring of plugins until "Cordova 2.x"
Posted by Brian LeRoux <b...@brian.io>.
I'm far more in favor of shims that barf deprecation notices than
maintaining two branches.
Bryce/Patrick: I'll kick up a separate thread about roadmapping plugin stuff.
On Mon, Mar 26, 2012 at 11:31 AM, Shazron <sh...@gmail.com> wrote:
> I haven't done any JavaScript shims but I've eased the pain for users
> needing to use plugins by adding compatibility headers for all the
> PhoneGap/Cordova versions out there (0.96 to 1.5.0). See my plugin in
> this issue and its README:
> https://issues.apache.org/jira/browse/CB-330
>
> These compat. headers I include in CordovaLib but is so far
> undocumented. What the procedure is, you would write a plugin meant
> for 1.6.0 (ie the latest version), and for older version support, a
> dev would included the appropriate compatibility headers.
>
> It's working great so far for the CDVLocalStorage plugin - from the
> same plugin code base (one .m and .h) through the compat. headers,
> everything just works with older versions as well. I assume we can do
> something similar for JavaScript as well (shims).
>
> Shaz
>
> On Mon, Mar 26, 2012 at 11:15 AM, Bryce Curtis <cu...@gmail.com> wrote:
>> I agree that there's no way to know what plugins will look like in 2.x.
>> Until then, I strongly believe we need to maintain the same (undocumented)
>> API that plugins currently rely upon, with the goal that 3rd party plugins
>> won't need to be updated again until 2.x - They already took a hit with
>> renaming in 1.5.
>>
>> Regarding the plugin APIs (JS & native), we can't identify with certainty
>> which ones will be deprecated until we are further along with the 2.x
>> plugin architecture, so we shouldn't confuse users until details are worked
>> out and prototypes running. Regarding API stability, while we have
>> discussed deprecating methods like addConstructor, window.plugins, etc.,
>> the fact that they have remained consistent for many releases (well over a
>> year or 2) has led to their wide use.
>>
>> After 1.6.0 release, we should schedule a plugin meeting to go over the
>> priorities, what's been done to date, and where it's going.
>>
>> On Mon, Mar 26, 2012 at 1:05 PM, Filip Maj <fi...@adobe.com> wrote:
>>
>>> Thanks Brian, I was just going to respond saying the same thing but you
>>> beat me to it!
>>>
>>> >What I'm trying to say is that I'm not at all inclined to +1/-1 until
>>> >we have agreed on the particulars of the change we seek.
>>>
>>> ^^ The above is the underlying issue. I suggest we do that as a first step.
>>>
>>> The referenced bug in this thread is just a small part of the overall
>>> work. Side note: deprecating + removing the "PhoneGap" JS global is not
>>> necessarily for plugins, it's a part of the Apache rename. The only
>>> changing part of the bug is removal of window.plugins. I prototyped a
>>> deprecation approach in a branch here (diff view):
>>> https://github.com/filmaj/incubator-cordova-js/compare/masterŠdeprecation
>>>
>>> Re: addResource/hasResource. These do not exist in cordova-js right now.
>>> They are effectively gone. They were only there for BB + Android anyways.
>>> I had one dude on IRC complain that we removed that in 1.5.0 without first
>>> deprecating. No huge outcry. Not saying that the fact we just axed it is
>>> good - it wasn't. We should have deprecated first, no doubt. My point
>>> about these two specific methods is, it already happened last release, so
>>> it is a moot point to discuss.
>>>
>>> Additionally we have had some work done to try to prototype what a final
>>> plugins-based approach to app development would look like, specifically
>>> Andrew Lunny's "pluginstall" work (which I believe started from a
>>> thread/discussion that happened on the list between Andrew and Pat). Here:
>>> https://github.com/alunny/pluginstall
>>>
>>> Andrew is most of the way there in terms of defining an XML file
>>> describing the integration of native source for a plugin, see:
>>> https://github.com/alunny/pluginstall/blob/master/test/plugin/plugin.xml
>>>
>>> The native plugin architecture has been around for a while. It is stable.
>>> Not much needs to be done there.
>>>
>>> The biggest question in my mind is how we want to handle the JavaScript.
>>> With cordova-js already implementing a basic module system with a hard API
>>> for the exec() function, we're actually not too far away.
>>>
>>> We should keep going in enumerating all these things that make up the
>>> plugin goal in this thread and drop whatever else comes up into a wiki
>>> page.
>>>
>>> It seems like it is a "safer" idea to slate all the plugin changes / API
>>> removals for 2.0. That being said, can we agree to drop deprecation
>>> notices into the agreed-upon APIs that will be axed leading up to 2.0?
>>>
>>> > I think we
>>> >can agree on the spirit of the focus of the work being a world of
>>> >plugins and tooling for automation. We haven't added much outside of
>>> >battery (and a new platform).
>>> >
>>> >1. The plugin architecture remains completely undocumented.
>>> >2. We do not support 3rd party plugins.
>>> >3. There is no automation or tooling.
>>> >
>>> >Are plugins from an API standpoint stable today? (I'm guessing not
>>> >when I think of things like addConstructor.)
>>> >
>>> >If they aren't stable, undocumented, unsupported by our effort, and a
>>> >work in progress for tooling: why are we concerned with breaking them?
>>> >
>>> >(Take all above with grain of salt, I think having a 2.x branch a good
>>> >idea, but will slow us down for no direct benefit to Cordova that I
>>> >can currently see.)
>>>
>>>
Re: endless refactoring of plugins until "Cordova 2.x"
Posted by Shazron <sh...@gmail.com>.
I haven't done any JavaScript shims but I've eased the pain for users
needing to use plugins by adding compatibility headers for all the
PhoneGap/Cordova versions out there (0.96 to 1.5.0). See my plugin in
this issue and its README:
https://issues.apache.org/jira/browse/CB-330
These compat. headers I include in CordovaLib but is so far
undocumented. What the procedure is, you would write a plugin meant
for 1.6.0 (ie the latest version), and for older version support, a
dev would included the appropriate compatibility headers.
It's working great so far for the CDVLocalStorage plugin - from the
same plugin code base (one .m and .h) through the compat. headers,
everything just works with older versions as well. I assume we can do
something similar for JavaScript as well (shims).
Shaz
On Mon, Mar 26, 2012 at 11:15 AM, Bryce Curtis <cu...@gmail.com> wrote:
> I agree that there's no way to know what plugins will look like in 2.x.
> Until then, I strongly believe we need to maintain the same (undocumented)
> API that plugins currently rely upon, with the goal that 3rd party plugins
> won't need to be updated again until 2.x - They already took a hit with
> renaming in 1.5.
>
> Regarding the plugin APIs (JS & native), we can't identify with certainty
> which ones will be deprecated until we are further along with the 2.x
> plugin architecture, so we shouldn't confuse users until details are worked
> out and prototypes running. Regarding API stability, while we have
> discussed deprecating methods like addConstructor, window.plugins, etc.,
> the fact that they have remained consistent for many releases (well over a
> year or 2) has led to their wide use.
>
> After 1.6.0 release, we should schedule a plugin meeting to go over the
> priorities, what's been done to date, and where it's going.
>
> On Mon, Mar 26, 2012 at 1:05 PM, Filip Maj <fi...@adobe.com> wrote:
>
>> Thanks Brian, I was just going to respond saying the same thing but you
>> beat me to it!
>>
>> >What I'm trying to say is that I'm not at all inclined to +1/-1 until
>> >we have agreed on the particulars of the change we seek.
>>
>> ^^ The above is the underlying issue. I suggest we do that as a first step.
>>
>> The referenced bug in this thread is just a small part of the overall
>> work. Side note: deprecating + removing the "PhoneGap" JS global is not
>> necessarily for plugins, it's a part of the Apache rename. The only
>> changing part of the bug is removal of window.plugins. I prototyped a
>> deprecation approach in a branch here (diff view):
>> https://github.com/filmaj/incubator-cordova-js/compare/masterŠdeprecation
>>
>> Re: addResource/hasResource. These do not exist in cordova-js right now.
>> They are effectively gone. They were only there for BB + Android anyways.
>> I had one dude on IRC complain that we removed that in 1.5.0 without first
>> deprecating. No huge outcry. Not saying that the fact we just axed it is
>> good - it wasn't. We should have deprecated first, no doubt. My point
>> about these two specific methods is, it already happened last release, so
>> it is a moot point to discuss.
>>
>> Additionally we have had some work done to try to prototype what a final
>> plugins-based approach to app development would look like, specifically
>> Andrew Lunny's "pluginstall" work (which I believe started from a
>> thread/discussion that happened on the list between Andrew and Pat). Here:
>> https://github.com/alunny/pluginstall
>>
>> Andrew is most of the way there in terms of defining an XML file
>> describing the integration of native source for a plugin, see:
>> https://github.com/alunny/pluginstall/blob/master/test/plugin/plugin.xml
>>
>> The native plugin architecture has been around for a while. It is stable.
>> Not much needs to be done there.
>>
>> The biggest question in my mind is how we want to handle the JavaScript.
>> With cordova-js already implementing a basic module system with a hard API
>> for the exec() function, we're actually not too far away.
>>
>> We should keep going in enumerating all these things that make up the
>> plugin goal in this thread and drop whatever else comes up into a wiki
>> page.
>>
>> It seems like it is a "safer" idea to slate all the plugin changes / API
>> removals for 2.0. That being said, can we agree to drop deprecation
>> notices into the agreed-upon APIs that will be axed leading up to 2.0?
>>
>> > I think we
>> >can agree on the spirit of the focus of the work being a world of
>> >plugins and tooling for automation. We haven't added much outside of
>> >battery (and a new platform).
>> >
>> >1. The plugin architecture remains completely undocumented.
>> >2. We do not support 3rd party plugins.
>> >3. There is no automation or tooling.
>> >
>> >Are plugins from an API standpoint stable today? (I'm guessing not
>> >when I think of things like addConstructor.)
>> >
>> >If they aren't stable, undocumented, unsupported by our effort, and a
>> >work in progress for tooling: why are we concerned with breaking them?
>> >
>> >(Take all above with grain of salt, I think having a 2.x branch a good
>> >idea, but will slow us down for no direct benefit to Cordova that I
>> >can currently see.)
>>
>>
Re: endless refactoring of plugins until "Cordova 2.x"
Posted by Bryce Curtis <cu...@gmail.com>.
I agree that there's no way to know what plugins will look like in 2.x.
Until then, I strongly believe we need to maintain the same (undocumented)
API that plugins currently rely upon, with the goal that 3rd party plugins
won't need to be updated again until 2.x - They already took a hit with
renaming in 1.5.
Regarding the plugin APIs (JS & native), we can't identify with certainty
which ones will be deprecated until we are further along with the 2.x
plugin architecture, so we shouldn't confuse users until details are worked
out and prototypes running. Regarding API stability, while we have
discussed deprecating methods like addConstructor, window.plugins, etc.,
the fact that they have remained consistent for many releases (well over a
year or 2) has led to their wide use.
After 1.6.0 release, we should schedule a plugin meeting to go over the
priorities, what's been done to date, and where it's going.
On Mon, Mar 26, 2012 at 1:05 PM, Filip Maj <fi...@adobe.com> wrote:
> Thanks Brian, I was just going to respond saying the same thing but you
> beat me to it!
>
> >What I'm trying to say is that I'm not at all inclined to +1/-1 until
> >we have agreed on the particulars of the change we seek.
>
> ^^ The above is the underlying issue. I suggest we do that as a first step.
>
> The referenced bug in this thread is just a small part of the overall
> work. Side note: deprecating + removing the "PhoneGap" JS global is not
> necessarily for plugins, it's a part of the Apache rename. The only
> changing part of the bug is removal of window.plugins. I prototyped a
> deprecation approach in a branch here (diff view):
> https://github.com/filmaj/incubator-cordova-js/compare/masterŠdeprecation
>
> Re: addResource/hasResource. These do not exist in cordova-js right now.
> They are effectively gone. They were only there for BB + Android anyways.
> I had one dude on IRC complain that we removed that in 1.5.0 without first
> deprecating. No huge outcry. Not saying that the fact we just axed it is
> good - it wasn't. We should have deprecated first, no doubt. My point
> about these two specific methods is, it already happened last release, so
> it is a moot point to discuss.
>
> Additionally we have had some work done to try to prototype what a final
> plugins-based approach to app development would look like, specifically
> Andrew Lunny's "pluginstall" work (which I believe started from a
> thread/discussion that happened on the list between Andrew and Pat). Here:
> https://github.com/alunny/pluginstall
>
> Andrew is most of the way there in terms of defining an XML file
> describing the integration of native source for a plugin, see:
> https://github.com/alunny/pluginstall/blob/master/test/plugin/plugin.xml
>
> The native plugin architecture has been around for a while. It is stable.
> Not much needs to be done there.
>
> The biggest question in my mind is how we want to handle the JavaScript.
> With cordova-js already implementing a basic module system with a hard API
> for the exec() function, we're actually not too far away.
>
> We should keep going in enumerating all these things that make up the
> plugin goal in this thread and drop whatever else comes up into a wiki
> page.
>
> It seems like it is a "safer" idea to slate all the plugin changes / API
> removals for 2.0. That being said, can we agree to drop deprecation
> notices into the agreed-upon APIs that will be axed leading up to 2.0?
>
> > I think we
> >can agree on the spirit of the focus of the work being a world of
> >plugins and tooling for automation. We haven't added much outside of
> >battery (and a new platform).
> >
> >1. The plugin architecture remains completely undocumented.
> >2. We do not support 3rd party plugins.
> >3. There is no automation or tooling.
> >
> >Are plugins from an API standpoint stable today? (I'm guessing not
> >when I think of things like addConstructor.)
> >
> >If they aren't stable, undocumented, unsupported by our effort, and a
> >work in progress for tooling: why are we concerned with breaking them?
> >
> >(Take all above with grain of salt, I think having a 2.x branch a good
> >idea, but will slow us down for no direct benefit to Cordova that I
> >can currently see.)
>
>
Re: endless refactoring of plugins until "Cordova 2.x"
Posted by Drew Walters <de...@gmail.com>.
I would be shocked if we've done all the breaking we're going to do
:-) Seems like at least the changes to make everything a plugin and
provide tooling around plugins will at a minimum change the format of
how plugins are provided and the documentation on how to install them,
which I would consider breaks.
On Wed, Mar 28, 2012 at 3:02 PM, Brian LeRoux <b...@brian.io> wrote:
> Looking at the proposed [1] roadmap [2] ....I'm not sure there's much
> left to break!!! (As in, I think we "done broke" all the things
> already.)
>
> Feels like the consensus is that our focus in the coming months
> leading to 2x is to be: docs, tests, "hardening" the code and tools
> for managing the plugins themselves.
>
> [1] http://goo.gl/1yAjD
> [2] http://wiki.apache.org/cordova/RoadmapProjects
>
>
>
>
>
>
> On Wed, Mar 28, 2012 at 12:37 PM, Jesse <pu...@gmail.com> wrote:
>> I agree with Fil, there is not that much that is broken with recent changes.
>> I think deprecation notices would be sufficient, and we can maintain those
>> interfaces until 2.0. ( in the past I think we were too quick with
>> deprecating and destroying )
>> IMHO maintaining 2 branches would make life worse, not better. ( for our
>> users, not just us )
>>
>> On Wed, Mar 28, 2012 at 12:04 PM, Patrick Mueller <pm...@gmail.com> wrote:
>>
>>> On Wed, Mar 28, 2012 at 14:44, Brian LeRoux <b...@brian.io> wrote:
>>>
>>> > 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.
>>> >
>>>
>>> Fair enough. And I understand your concern.
>>>
>>> I'll write up a proposal on the wiki, and post a new top-level thread on
>>> the m/l when I got something.
>>>
>>> --
>>> Patrick Mueller
>>> http://muellerware.org
>>>
Re: endless refactoring of plugins until "Cordova 2.x"
Posted by Brian LeRoux <b...@brian.io>.
Looking at the proposed [1] roadmap [2] ....I'm not sure there's much
left to break!!! (As in, I think we "done broke" all the things
already.)
Feels like the consensus is that our focus in the coming months
leading to 2x is to be: docs, tests, "hardening" the code and tools
for managing the plugins themselves.
[1] http://goo.gl/1yAjD
[2] http://wiki.apache.org/cordova/RoadmapProjects
On Wed, Mar 28, 2012 at 12:37 PM, Jesse <pu...@gmail.com> wrote:
> I agree with Fil, there is not that much that is broken with recent changes.
> I think deprecation notices would be sufficient, and we can maintain those
> interfaces until 2.0. ( in the past I think we were too quick with
> deprecating and destroying )
> IMHO maintaining 2 branches would make life worse, not better. ( for our
> users, not just us )
>
> On Wed, Mar 28, 2012 at 12:04 PM, Patrick Mueller <pm...@gmail.com> wrote:
>
>> On Wed, Mar 28, 2012 at 14:44, Brian LeRoux <b...@brian.io> wrote:
>>
>> > 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.
>> >
>>
>> Fair enough. And I understand your concern.
>>
>> I'll write up a proposal on the wiki, and post a new top-level thread on
>> the m/l when I got something.
>>
>> --
>> Patrick Mueller
>> http://muellerware.org
>>
Re: endless refactoring of plugins until "Cordova 2.x"
Posted by Jesse <pu...@gmail.com>.
I agree with Fil, there is not that much that is broken with recent changes.
I think deprecation notices would be sufficient, and we can maintain those
interfaces until 2.0. ( in the past I think we were too quick with
deprecating and destroying )
IMHO maintaining 2 branches would make life worse, not better. ( for our
users, not just us )
On Wed, Mar 28, 2012 at 12:04 PM, Patrick Mueller <pm...@gmail.com> wrote:
> On Wed, Mar 28, 2012 at 14:44, Brian LeRoux <b...@brian.io> wrote:
>
> > 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.
> >
>
> Fair enough. And I understand your concern.
>
> I'll write up a proposal on the wiki, and post a new top-level thread on
> the m/l when I got something.
>
> --
> Patrick Mueller
> http://muellerware.org
>
Re: endless refactoring of plugins until "Cordova 2.x"
Posted by Patrick Mueller <pm...@gmail.com>.
On Wed, Mar 28, 2012 at 14:44, Brian LeRoux <b...@brian.io> wrote:
> 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.
>
Fair enough. And I understand your concern.
I'll write up a proposal on the wiki, and post a new top-level thread on
the m/l when I got something.
--
Patrick Mueller
http://muellerware.org
Re: endless refactoring of plugins until "Cordova 2.x"
Posted by Filip Maj <fi...@adobe.com>.
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" <si...@gmail.com> 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
>http://hi.im/simonmacdonald
>
>
>
>On Wed, Mar 28, 2012 at 2:44 PM, Brian LeRoux <b...@brian.io> 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
>> <si...@gmail.com> 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
>>> http://hi.im/simonmacdonald
>>>
>>>
>>>
>>> On Wed, Mar 28, 2012 at 1:05 PM, Filip Maj <fi...@adobe.com> 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]
>>>>
>>>>http://git-wip-us.apache.org/repos/asf?p=incubator-cordova-mobile-spec.
>>>>git;
>>>> a=commit;h=79a84e59383501f1cccb025e64e35e31d284aac4
>>>>
>>>> On 3/28/12 9:59 AM, "Patrick Mueller" <pm...@gmail.com> wrote:
>>>>
>>>>>On Wed, Mar 28, 2012 at 12:22, Brian LeRoux <b...@brian.io> 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
>>>>>lifetime.
>>>>>
>>>>>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"
>>>>>
>>>>> http://www.youtube.com/watch?v=jyaLZHiJJnE
>>>>>
>>>>>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
>>>>>http://muellerware.org
>>>>
Re: endless refactoring of plugins until "Cordova 2.x"
Posted by Simon MacDonald <si...@gmail.com>.
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
http://hi.im/simonmacdonald
On Wed, Mar 28, 2012 at 2:44 PM, Brian LeRoux <b...@brian.io> 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
> <si...@gmail.com> 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
>> http://hi.im/simonmacdonald
>>
>>
>>
>> On Wed, Mar 28, 2012 at 1:05 PM, Filip Maj <fi...@adobe.com> 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]
>>> http://git-wip-us.apache.org/repos/asf?p=incubator-cordova-mobile-spec.git;
>>> a=commit;h=79a84e59383501f1cccb025e64e35e31d284aac4
>>>
>>> On 3/28/12 9:59 AM, "Patrick Mueller" <pm...@gmail.com> wrote:
>>>
>>>>On Wed, Mar 28, 2012 at 12:22, Brian LeRoux <b...@brian.io> 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
>>>>lifetime.
>>>>
>>>>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"
>>>>
>>>> http://www.youtube.com/watch?v=jyaLZHiJJnE
>>>>
>>>>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
>>>>http://muellerware.org
>>>
Re: endless refactoring of plugins until "Cordova 2.x"
Posted by Brian LeRoux <b...@brian.io>.
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
<si...@gmail.com> 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
> http://hi.im/simonmacdonald
>
>
>
> On Wed, Mar 28, 2012 at 1:05 PM, Filip Maj <fi...@adobe.com> 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]
>> http://git-wip-us.apache.org/repos/asf?p=incubator-cordova-mobile-spec.git;
>> a=commit;h=79a84e59383501f1cccb025e64e35e31d284aac4
>>
>> On 3/28/12 9:59 AM, "Patrick Mueller" <pm...@gmail.com> wrote:
>>
>>>On Wed, Mar 28, 2012 at 12:22, Brian LeRoux <b...@brian.io> 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
>>>lifetime.
>>>
>>>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"
>>>
>>> http://www.youtube.com/watch?v=jyaLZHiJJnE
>>>
>>>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
>>>http://muellerware.org
>>
Re: endless refactoring of plugins until "Cordova 2.x"
Posted by Simon MacDonald <si...@gmail.com>.
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
http://hi.im/simonmacdonald
On Wed, Mar 28, 2012 at 1:05 PM, Filip Maj <fi...@adobe.com> 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]
> http://git-wip-us.apache.org/repos/asf?p=incubator-cordova-mobile-spec.git;
> a=commit;h=79a84e59383501f1cccb025e64e35e31d284aac4
>
> On 3/28/12 9:59 AM, "Patrick Mueller" <pm...@gmail.com> wrote:
>
>>On Wed, Mar 28, 2012 at 12:22, Brian LeRoux <b...@brian.io> 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
>>lifetime.
>>
>>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"
>>
>> http://www.youtube.com/watch?v=jyaLZHiJJnE
>>
>>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
>>http://muellerware.org
>
Re: endless refactoring of plugins until "Cordova 2.x"
Posted by Simon MacDonald <si...@gmail.com>.
I have to agree with Pat. There is no way we can continue to support
third party plugins and continue to move PG forward the way we are
working. Adopting two separate streams would be a good idea.
We can't keep on with the dichotomy where on one hand we tell people
that if PhoneGap is missing some functionality to go write a plugin
while on the other hand we tell them third party plugins are not
supported and could get broken on every new release.
We should pick a point in the future, 2.0 sounds good, to introduce a
new plugin API that will break the plugins once and only once while on
the 1.X stream each new release will support the plugins already
written.
Simon Mac Donald
http://hi.im/simonmacdonald
On Wed, Mar 28, 2012 at 12:59 PM, Patrick Mueller <pm...@gmail.com> wrote:
> On Wed, Mar 28, 2012 at 12:22, Brian LeRoux <b...@brian.io> 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
> lifetime.
>
> 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"
>
> http://www.youtube.com/watch?v=jyaLZHiJJnE
>
> 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
> http://muellerware.org
Re: endless refactoring of plugins until "Cordova 2.x"
Posted by Filip Maj <fi...@adobe.com>.
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]
http://git-wip-us.apache.org/repos/asf?p=incubator-cordova-mobile-spec.git;
a=commit;h=79a84e59383501f1cccb025e64e35e31d284aac4
On 3/28/12 9:59 AM, "Patrick Mueller" <pm...@gmail.com> wrote:
>On Wed, Mar 28, 2012 at 12:22, Brian LeRoux <b...@brian.io> 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
>lifetime.
>
>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"
>
> http://www.youtube.com/watch?v=jyaLZHiJJnE
>
>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
>http://muellerware.org
Re: endless refactoring of plugins until "Cordova 2.x"
Posted by Patrick Mueller <pm...@gmail.com>.
On Wed, Mar 28, 2012 at 12:22, Brian LeRoux <b...@brian.io> 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
lifetime.
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"
http://www.youtube.com/watch?v=jyaLZHiJJnE
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
http://muellerware.org
Re: endless refactoring of plugins until "Cordova 2.x"
Posted by Brian LeRoux <b...@brian.io>.
> It just doesn't jive with the story I think you're telling with your list,
> at least the first two points. There is at least *implied* support for 3rd
> party plugins today.
*sigh*
It may, or may not, surprise you to learn that I have little to no say
in Adobe's evang team activities. Though I can assure you its not the
first time I've been embarrassed by them! =) Saying that, I'm obv
happy too they are doing this. The more support we get the better.
Now that said, I don't count that as documentation for Apache Cordova
(nor do I think you or anyone here does). If it isn't in
http://git-wip-us.apache.org/repos/asf then does it matter? Just
shipping the code in itself implies some level of support I suppose.
What are we looking for as a resolution here? Commit that 1.7 we
document the plugin api?
Re: endless refactoring of plugins until "Cordova 2.x"
Posted by Patrick Mueller <pm...@gmail.com>.
On Mon, Mar 26, 2012 at 13:43, Brian LeRoux <b...@brian.io> wrote:
> 1. The plugin architecture remains completely undocumented.
> 2. We do not support 3rd party plugins.
> 3. There is no automation or tooling.
>
and yet, posted today:
http://www.adobe.com/devnet/html5/articles/extending-phonegap-with-native-plugins-for-ios.html
I should note, I LURVES seeing articles like this - I'm sure we'll have
IBMers doing the same on our developerWorks site (over time, if we haven't
already).
It just doesn't jive with the story I think you're telling with your list,
at least the first two points. There is at least *implied* support for 3rd
party plugins today.
--
Patrick Mueller
http://muellerware.org
Re: endless refactoring of plugins until "Cordova 2.x"
Posted by Filip Maj <fi...@adobe.com>.
>https://github.com/filmaj/incubator-cordova-js/compare/masterŠdeprecation
Stupid outlook messing with my urls >:|. Correct link:
https://github.com/filmaj/incubator-cordova-js/compare/master...deprecation
Re: endless refactoring of plugins until "Cordova 2.x"
Posted by Filip Maj <fi...@adobe.com>.
Thanks Brian, I was just going to respond saying the same thing but you
beat me to it!
>What I'm trying to say is that I'm not at all inclined to +1/-1 until
>we have agreed on the particulars of the change we seek.
^^ The above is the underlying issue. I suggest we do that as a first step.
The referenced bug in this thread is just a small part of the overall
work. Side note: deprecating + removing the "PhoneGap" JS global is not
necessarily for plugins, it's a part of the Apache rename. The only
changing part of the bug is removal of window.plugins. I prototyped a
deprecation approach in a branch here (diff view):
https://github.com/filmaj/incubator-cordova-js/compare/masterŠdeprecation
Re: addResource/hasResource. These do not exist in cordova-js right now.
They are effectively gone. They were only there for BB + Android anyways.
I had one dude on IRC complain that we removed that in 1.5.0 without first
deprecating. No huge outcry. Not saying that the fact we just axed it is
good - it wasn't. We should have deprecated first, no doubt. My point
about these two specific methods is, it already happened last release, so
it is a moot point to discuss.
Additionally we have had some work done to try to prototype what a final
plugins-based approach to app development would look like, specifically
Andrew Lunny's "pluginstall" work (which I believe started from a
thread/discussion that happened on the list between Andrew and Pat). Here:
https://github.com/alunny/pluginstall
Andrew is most of the way there in terms of defining an XML file
describing the integration of native source for a plugin, see:
https://github.com/alunny/pluginstall/blob/master/test/plugin/plugin.xml
The native plugin architecture has been around for a while. It is stable.
Not much needs to be done there.
The biggest question in my mind is how we want to handle the JavaScript.
With cordova-js already implementing a basic module system with a hard API
for the exec() function, we're actually not too far away.
We should keep going in enumerating all these things that make up the
plugin goal in this thread and drop whatever else comes up into a wiki
page.
It seems like it is a "safer" idea to slate all the plugin changes / API
removals for 2.0. That being said, can we agree to drop deprecation
notices into the agreed-upon APIs that will be axed leading up to 2.0?
> I think we
>can agree on the spirit of the focus of the work being a world of
>plugins and tooling for automation. We haven't added much outside of
>battery (and a new platform).
>
>1. The plugin architecture remains completely undocumented.
>2. We do not support 3rd party plugins.
>3. There is no automation or tooling.
>
>Are plugins from an API standpoint stable today? (I'm guessing not
>when I think of things like addConstructor.)
>
>If they aren't stable, undocumented, unsupported by our effort, and a
>work in progress for tooling: why are we concerned with breaking them?
>
>(Take all above with grain of salt, I think having a 2.x branch a good
>idea, but will slow us down for no direct benefit to Cordova that I
>can currently see.)
Re: endless refactoring of plugins until "Cordova 2.x"
Posted by Brian LeRoux <b...@brian.io>.
> The problem is, we don't know what 2.x looks like, in the end, so WE HAVE
> NO IDEA WHAT WILL CHANGE. Having a separate 2.x stream lets us figure out
> what will change, independent of further 1.x releases.
So, we agree there will be change in a software project. =)
What I'm trying to say is that I'm not at all inclined to +1/-1 until
we have agreed on the particulars of the change we seek. I think we
can agree on the spirit of the focus of the work being a world of
plugins and tooling for automation. We haven't added much outside of
battery (and a new platform).
1. The plugin architecture remains completely undocumented.
2. We do not support 3rd party plugins.
3. There is no automation or tooling.
Are plugins from an API standpoint stable today? (I'm guessing not
when I think of things like addConstructor.)
If they aren't stable, undocumented, unsupported by our effort, and a
work in progress for tooling: why are we concerned with breaking them?
(Take all above with grain of salt, I think having a 2.x branch a good
idea, but will slow us down for no direct benefit to Cordova that I
can currently see.)
Re: endless refactoring of plugins until "Cordova 2.x"
Posted by Patrick Mueller <pm...@gmail.com>.
On Mon, Mar 26, 2012 at 12:08, Brian LeRoux <b...@brian.io> wrote:
> On one hand I buy into this to shield from change and allow ppl time
> to migrate. On the other, thats the point of a point release to me. To
> make the migration incremental so that 2.x does NOT break all the
> things and is viewed as a fucked up release.
>
We seem to have been saying all along "plugins will need to change". And I
think it's a given, plugins will be in a different shape for 2.x than where
they're at in 1.5 (just to pick a particular 1.x release).
I'd just rather not have to say for every 1.x release from here on out -
"plugins will need to change". I'd rather do that once, at some point in
the future, for 2.x.
> This will mean 2.x work stays in a branch and has to be constantly
> rebased which may be really painful for implementors.
>
Yes, there will be some rebasing pain with a separate stream. One thing
that would make life a little easier, for the "core" plugins, would be to
say that in the 2.x stream, they will not have "fixes" from 1.x rebased
into them. They'll remain at 1.x level functionality/bugs/etc. The main
point of 2.x is to get a new stable core and plugin architecture - the
actual meat of the plugins doesn't matter as much as that.
When we're finished cooking 2.x, then we rebase the core plugins, which
will give us some great experience in telling people how to rebase their
own plugins.
> Either way, separation of bugs from new-ness smells pragmatic; and I
> know we share the same goals here of plugins for everything. Before we
> go ahead w/ the assumption everything from here is drastic can we
> first outline exactly what happens next?
>
> ... <things that will change>
>
The problem is, we don't know what 2.x looks like, in the end, so WE HAVE
NO IDEA WHAT WILL CHANGE. Having a separate 2.x stream lets us figure out
what will change, independent of further 1.x releases.
--
Patrick Mueller
http://muellerware.org
Re: endless refactoring of plugins until "Cordova 2.x"
Posted by Brian LeRoux <b...@brian.io>.
On one hand I buy into this to shield from change and allow ppl time
to migrate. On the other, thats the point of a point release to me. To
make the migration incremental so that 2.x does NOT break all the
things and is viewed as a fucked up release.
This will mean 2.x work stays in a branch and has to be constantly
rebased which may be really painful for implementors.
Either way, separation of bugs from new-ness smells pragmatic; and I
know we share the same goals here of plugins for everything. Before we
go ahead w/ the assumption everything from here is drastic can we
first outline exactly what happens next?
- Removal of undocumented but in use globals.
- Consolidation of tooling for plugin package validation,
installation, and removal.
- Refactor of native code into discreet packages across platforms into
atomic units called plugins. Eg. cordova-plugin-geolocation
- Refacotor coho to allow for composing a release of particular plugins.
- Document correct procedure for generating a plugin.
- Automate plugin discovery ala npm/cpan/rubygems/pypi/etc.
What am I missing? Lets update the roadmap so we can allow ppl to stay
bleeding towards 2.x and be on the same page for whats happening next.
Agree, plugins are in a hard way right now but this is all for the
better for them!
On Mon, Mar 26, 2012 at 7:11 AM, Drew Walters <de...@gmail.com> wrote:
> +1 to 2.0 development stream. Too many structural level changes are
> happening between releases right now.
>
> On Mon, Mar 26, 2012 at 9:07 AM, Simon MacDonald
> <si...@gmail.com> wrote:
>> I would love to see this too stream approach moving forward with Cordova
>> until the 2.0 release.
>>
>> Simon Mac Donald
>> http://hi.im/simonmacdonald
>>
>>
>> On Mon, Mar 26, 2012 at 10:00 AM, Patrick Mueller <pm...@gmail.com> wrote:
>>
>>> see:
>>> https://issues.apache.org/jira/browse/CB-298
>>> "DEPRECATE and then remove "plugins" and "PhoneGap" global objects from
>>> JavaScript implementation"
>>>
>>> So, at this point, it looks like anyone with plugins who wants to follow
>>> the Cordova releases will be in a constant state of refactoring to
>>> accommodate each new point release. That is so painful.
>>>
>>> Add to this, our release cycle is 4 weeks, so we realistically have a
>>> couple of weeks to implement refactorings, such as described in the
>>> referenced bug. Which means we don't have a lot of time to capture
>>> feedback from those refactorings before they become "new API".
>>>
>>> This really isn't great.
>>>
>>> I think at this point, I'd like to freeze the 1.x "API", and have a
>>> separate stream of development for 2.x.
>>>
>>> Downside:
>>>
>>> - separate streams of development
>>>
>>> Upside:
>>>
>>> - easier to stabilize 1.x level API
>>> - longer-lived streams of development for 2.x
>>> - most folks will only have to refactor their plugins once, from 1.x to
>>> 2.0, instead of 1.5 -> 1.6, 1.6 -> 1.7, ...
>>>
>>> --
>>> Patrick Mueller
>>> http://muellerware.org
>>>
Re: endless refactoring of plugins until "Cordova 2.x"
Posted by Drew Walters <de...@gmail.com>.
+1 to 2.0 development stream. Too many structural level changes are
happening between releases right now.
On Mon, Mar 26, 2012 at 9:07 AM, Simon MacDonald
<si...@gmail.com> wrote:
> I would love to see this too stream approach moving forward with Cordova
> until the 2.0 release.
>
> Simon Mac Donald
> http://hi.im/simonmacdonald
>
>
> On Mon, Mar 26, 2012 at 10:00 AM, Patrick Mueller <pm...@gmail.com> wrote:
>
>> see:
>> https://issues.apache.org/jira/browse/CB-298
>> "DEPRECATE and then remove "plugins" and "PhoneGap" global objects from
>> JavaScript implementation"
>>
>> So, at this point, it looks like anyone with plugins who wants to follow
>> the Cordova releases will be in a constant state of refactoring to
>> accommodate each new point release. That is so painful.
>>
>> Add to this, our release cycle is 4 weeks, so we realistically have a
>> couple of weeks to implement refactorings, such as described in the
>> referenced bug. Which means we don't have a lot of time to capture
>> feedback from those refactorings before they become "new API".
>>
>> This really isn't great.
>>
>> I think at this point, I'd like to freeze the 1.x "API", and have a
>> separate stream of development for 2.x.
>>
>> Downside:
>>
>> - separate streams of development
>>
>> Upside:
>>
>> - easier to stabilize 1.x level API
>> - longer-lived streams of development for 2.x
>> - most folks will only have to refactor their plugins once, from 1.x to
>> 2.0, instead of 1.5 -> 1.6, 1.6 -> 1.7, ...
>>
>> --
>> Patrick Mueller
>> http://muellerware.org
>>
Re: endless refactoring of plugins until "Cordova 2.x"
Posted by Simon MacDonald <si...@gmail.com>.
I would love to see this too stream approach moving forward with Cordova
until the 2.0 release.
Simon Mac Donald
http://hi.im/simonmacdonald
On Mon, Mar 26, 2012 at 10:00 AM, Patrick Mueller <pm...@gmail.com> wrote:
> see:
> https://issues.apache.org/jira/browse/CB-298
> "DEPRECATE and then remove "plugins" and "PhoneGap" global objects from
> JavaScript implementation"
>
> So, at this point, it looks like anyone with plugins who wants to follow
> the Cordova releases will be in a constant state of refactoring to
> accommodate each new point release. That is so painful.
>
> Add to this, our release cycle is 4 weeks, so we realistically have a
> couple of weeks to implement refactorings, such as described in the
> referenced bug. Which means we don't have a lot of time to capture
> feedback from those refactorings before they become "new API".
>
> This really isn't great.
>
> I think at this point, I'd like to freeze the 1.x "API", and have a
> separate stream of development for 2.x.
>
> Downside:
>
> - separate streams of development
>
> Upside:
>
> - easier to stabilize 1.x level API
> - longer-lived streams of development for 2.x
> - most folks will only have to refactor their plugins once, from 1.x to
> 2.0, instead of 1.5 -> 1.6, 1.6 -> 1.7, ...
>
> --
> Patrick Mueller
> http://muellerware.org
>