I'd like time for testing, esp. creating a checklist so we don't forget what needs to be updated each release - like getting started guides, etc. For example if a platform maintainer is away, things might get missed.
On Tue, Mar 27, 2012 at 4:22 PM, Bryce Curtis <curtis.br...@gmail.com> wrote: > In the recent past, releases have been about monthly - which was beneficial > to get fixes out to the community. However, this frequency seemed to take > precedence over getting larger changes completed and tested (lesson learned > from 1.5.0). For releases of substantial changes, it is better for the > community (and us) to take a bit longer so as to remain consistent across > platforms and have time to update docs, tests, etc. for that release. So, > I guess that equates to month cadence for small changes, >monthly for > significant features. I consider 1.6.0 a significant update, so a week or > two longer for docs/testing is acceptable with the goal to restore > confidence in the release. For longer term changes, phasing in is ok, but > it should not impact compatibility and docs need to indicate what's > currently new and where it's headed. > > On Tue, Mar 27, 2012 at 5:56 PM, Michael Brooks > <mich...@michaelbrooks.ca>wrote: > >> Great overview Brian. Thanks for that! >> >> I'd like to keep the short sprints going with the following focus points: >> >> - take on less each sprint >> - one project-wide milestone (movement towards an improved plugin >> structure) >> - one platform-specific milestone (adding new OS support, etc) >> - closing existing bugs >> - maintaining backwards compatibility with deprecation notices >> - higher emphasis on testing APIs >> - higher emphasis on testing documentation >> >> I feel that the short sprints have increased our communication and >> encouraged an improved release process (think back 1 - 1.5 years). >> >> Michael >> >> On Tue, Mar 27, 2012 at 3:17 PM, Brian LeRoux <b...@brian.io> wrote: >> >> > 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 <curtis.br...@gmail.com> >> > 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 <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. >> > >> >> > >>
