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 21:51:39 GMT
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