incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: 1.7 1.8 1.9 2.0rc planning, priorities, and plugins
Date Wed, 28 Mar 2012 19:56:02 GMT
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 <fil@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" <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