I incorporated the roadmap feedback into the wiki [1] and will start the checklist [2].
[1] http://wiki.apache.org/cordova/RoadmapProjects [2] http://wiki.apache.org/cordova/CuttingReleases On Tue, Mar 27, 2012 at 5:10 PM, Filip Maj <[email protected]> wrote: > 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. >>>> > >> >>>> > >>>> >
