Add to 1.6-1.7 - More focus on docs, guides, examples, maybe native plugin API - Advanced notice of what's planned to be deprecated and when, then get community feedback before breaking compatibility
1.7 - CordovaView (Android) 1.6-2.x - Emphasize testing to ensure no regression. - Quality releases are more important than schedule. On Tue, Mar 27, 2012 at 4:36 PM, Brian LeRoux <b...@brian.io> wrote: > The big theme this year has been migration to an architecture more > friendly to plugins with our ultimate goal of the end user being able > to compose their own version of Cordova with only the APIs they need. > Essentially our release would slowly strip down to webview+bridge and > then we'd maintain an official set of plugins separately (which are > comprised of the device apis we target today). > > From a high level to make this happen we need > > 1.6-1.7 March/April > > - a consistent js impl across platforms (almost there) > > 1.7-1.9 April/May/June > > - tooling for plugin package validation, installation, and removal > (andrew prototyping this) > - refactor of (possibly) coho to allow for composing a release of > particular plugins > - document correct procedure for generating a plugin or, better, have > a tool that does it > > 2.0.0rc1 July 15 > > Post 2.x > - automate plugin discovery ala npm/cpan/rubygems/pypi/etc > - remove plugins to discreet repos and use discovery mechanism to > compose different releases > > * * * > How does that fit with your thoughts on Apache Cordova? Future > releases can target, with surgical precision, particular APIs by way > of plugin with a faster prototype cycle and we can then also start > looking at more polish type activities like bridge performance, test > automation and the such. >
