1.7 1.8 1.9 2.0rc planning, priorities, and plugins

[Brian LeRoux <b...@brian.io>]

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.

Re: 1.7 1.8 1.9 2.0rc planning, priorities, and plugins

[Brian LeRoux <b...@brian.io>]

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 <fi...@adobe.com> 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" <sh...@gmail.com> 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 <cu...@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
>>><mi...@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
>>>><cu...@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.
>>>> > >>
>>>> >
>>>>
>

Re: 1.7 1.8 1.9 2.0rc planning, priorities, and plugins

[Filip Maj <fi...@adobe.com>]

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" <sh...@gmail.com> 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 <cu...@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
>><mi...@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
>>><cu...@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.
>>> > >>
>>> >
>>>

Re: 1.7 1.8 1.9 2.0rc planning, priorities, and plugins

[Shazron <sh...@gmail.com>]

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 <cu...@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 <mi...@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 <cu...@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.
>> > >>
>> >
>>

Re: 1.7 1.8 1.9 2.0rc planning, priorities, and plugins

[Bryce Curtis <cu...@gmail.com>]

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 <mi...@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 <cu...@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.
> > >>
> >
>

Re: 1.7 1.8 1.9 2.0rc planning, priorities, and plugins

[Michael Brooks <mi...@michaelbrooks.ca>]

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 <cu...@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.
> >>
>

Re: 1.7 1.8 1.9 2.0rc planning, priorities, and plugins

[Brian LeRoux <b...@brian.io>]

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 <cu...@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.
>>

Re: 1.7 1.8 1.9 2.0rc planning, priorities, and plugins

[Bryce Curtis <cu...@gmail.com>]

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.
>