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" <[email protected]> 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 <[email protected]> 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 <[email protected]> >>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 <[email protected]> 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.) >>>> >>>>
