incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: 1.7 1.8 1.9 2.0rc planning, priorities, and plugins
Date Tue, 27 Mar 2012 23:57:45 GMT
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.bryce@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 <michael@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.bryce@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.
>> > >>
>> >
>>

Mime
View raw message