incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryce Curtis <curtis.br...@gmail.com>
Subject Re: 1.7 1.8 1.9 2.0rc planning, priorities, and plugins
Date Tue, 27 Mar 2012 23:22:07 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message