I would love a checklist like that! How about dropping in another section to our CuttingReleases wiki article, I.e. Maintainer checklist before cutting a release?
On 3/27/12 4:57 PM, "Shazron" <[email protected]> wrote: >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 <[email protected]> >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 >><[email protected]>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 <[email protected]> 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 >>><[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. >>> > >> >>> > >>>
