The tacit plan is to observe the plugin installation/download counts to inform our decisions about what remains official and not. I suspect we maintain more stuff than our community currently uses or needs.
Also, agree w/ Andrew that we should start migrating docs to the plugins themselves. On Tue, Oct 15, 2013 at 2:23 PM, Andrew Grieve <agri...@chromium.org> wrote: > I think it depends on what your definition of "officially supported" is. If > it's that we'll try and fix bugs that arise in them, I think they are all > officially supported. > > In a 3.0 world, I think we'll move more towards having docs bundled with > plugins instead of hosted on docs.cordova.io, so I don't think the docs > are > indicative of what we will "officially support" > > > On Tue, Oct 15, 2013 at 2:17 PM, James Jong <wjamesj...@gmail.com> wrote: > > > As we're breaking out and developing more and more plugins, one question > I > > have been getting is "what is the set of plugins officially supported by > > the Cordova community?" It's unclear to me what defines this set. > Here's > > how I've been categorizing them. > > > > Supported > > 1) Publicly documented APIs on cordova.apache.org/docs (Accelerometer, > > Compass, etc…). These plugins fall under the org.apache.cordova > namespace. > > > > Unsupported > > 2) plugins not under org.apache.cordova namespace > > 3) org.apache.cordova plugins under cordova-labs (like the new iOS > > keyboard, status bar plugins) > > > > Gray areas > > 4) Undocumented plugins that were formerly part of the core. For > example, > > the console plugin. This is a org,apache.cordova plugin, but not > > documented as part of public APIs. Also, not all platforms support it. > > Should we support it? If we support it, should we document the API in > our > > Cordova docs? > > > > Thoughts? Should we have a list of supported plugins in our > documentation > > to point Cordova users to? > > > > -James Jong > > > > >
