incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: 1.7 1.8 1.9 2.0rc planning, priorities, and plugins
Date Wed, 28 Mar 2012 00:10:25 GMT
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" <shazron@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 <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