Bryce you think we start moving to >monthly sprints or just take on less each sprint?
I'd rather we kept the release train style though perhaps move to odd numbers fix bugs and even numbers are new features... though in the case of other projects I rarely see this actually work as advertised. On Tue, Mar 27, 2012 at 2:51 PM, Bryce Curtis <[email protected]> wrote: > 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 <[email protected]> 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. >>
