Published using Google Docs
Dojo Toolkit 1.7 Project
Updated automatically every 5 minutes

DOJO TOOLKIT 1.7

RElEASE Plan &

2011 Roadmap

(DRAFT)

Contents

Contents

Goals

2011-2012 Roadmap

Increased Delivery Pace

Release Themes

Maintenance Streams

Planned Release Content

Core Library

AMD-aware Build Tools

Asynchronous Loaders

has() Branching

Touch Specification

Dijit/Mobile refactoring

MVC for Dijit & Mobile

Mobile Widget Specification

Blackberrytm Mobile Theme & Custom Mobile Theme examples

Application Controller Library

GFX Enhancements for Mobile Scenarios

Mobile Charting Enhancements -

Gauges Enhancements

Unified Geo Mapping API

Dojo OpenLayers Map Provider

Gallery & Demos

Widget Gallery

Supported Browser Platforms

Desktop Browsers

Mobile Operating Systems (Dojo Core & Dojo Mobile only)

Marketing Improvements

Dojo 1.7 Schedule

Process & Procedure Changes

Alpha Development Phase (Milestone 1 - 6wks)

Closing down the Release (Milestone 2 - 6wks)

Test Plan (TODO)

Deferred Content

Packages & Plugins Specification

Package Repository & Manager

Grid


Goals

This paper outlines the project scope and priorities for the Dojo Toolkit 1.7 release, the release plan, and process changes necessary to meet the stated goals on time.

With the market shifting toward mobile and inclusion of mobile capabilities by Dojo’s traditional competitors that have made releases in the last six months to add mobile features to what were previously just desktop web toolkits, it is now critical that the Dojo community execute on the mobile roadmap outlined last year in Sept.  To be competitive in mobile, Dojo must expand it’s mobile widget features beyond the where the competition is currently at in the first half of 2011.  No other library has been able to demonstrate cross-browser mobile graphics as part of their library to date--this is a huge opportunity for Dojo to go beyond the competition, by updating GFX infrastructure and related graphical visualization modules (charts, gauges, maps, etc.). Demos and documentation must be provided for all of these mobile features, behind a quality marketing website.   With the introduction of mobile features, Dojo’s test and support matrix for browsers will expand rapidly.  Not every Dojo developer will have access to physical devices that their code need to support.  In Dojo 1.7, we must complete enhancements to the test automation infrastructure including making it possible to simulate touch events in DOH tests so that we can crowd-source tests as much as possible and continue to get good test coverage reports on all platforms on a continuous (goal: nightly) basis.

In conjunction with mobile, the community needs to continue it’s introduction of key features that will lay the foundation for Dojo 2.0 in the 1.8 timeframe in the second half of 2011.  Features such as async loader support (while maintaining compatibility with sync loaders in 1.x), package manager and build tool improvements which will position Dojo for multiple distributed repositories of project packages that can still be aggregated together to form a cohesive distribution.  Introduction of feature detection has() checks in the modules for build-time performance optimizations (but not yet exploiting has() within Dojo modules) will all be fundamental building blocks which will enable Dojo 2.0, and eventually enable Dojo to be more flexible with introducing new browser support on previous versions.  

It’s been a slow start toward getting resources in place to begin execution; however, at this time a number of companies are making large contributions intended to help Dojo meet its mobile goals in 2011.  For Dojo 1.7, we want to cut the time between releases in half, to get more airplay, and we believe that with appropriate coordination we can make this happen.   The remainder of this paper describes the plan and process changes which are being made to help the community meet the about goals for mobile and core enablement.

2011-2012 Roadmap

Increased Delivery Pace

In order to meet competitive goals, and pull ahead of competitors in terms of breadth of features and improved performance by year end, the Dojo community must increase the pace from half year average release frequency to quarterly release frequency during 2011.  

Releasing at this increased frequency requires that Dojo committers be better organized, have more forward planning than in previous releases.  The Dojo committers will need to be very smart about features integrated to maintain trunk stability, and stay focused on keeping features integrated to the scope defined for that release using.

Release Themes

The tentative themes planned for major future releases are defined in the following table.

1.7

Async Loading, AMD Builds, Basic Mobile Toolkit, Visualization Enhancements,

Add IE9/FF4 support (also in 1.6.1)

1.8

Advanced Mobile Controls, Complete Grid Plugins, Feature Detection Exploitation, Safari 6, Package Manager & Spec

1.9

“1.8 Feature Complete” - Final Bridge release to 2.0.  During the 1.8-1.9 release period, 2.0 development is fully underway.

1.9+

All 1.9+ releases will be maintenance and browser support only

2.0

First 2.0 release - Drop old API’s and codepaths.  Fully Async, Fully AMD, drop legacy globals.  Distributed repository and package management, aggregate distributed build.

Maintenance Streams

Between 1.6 and 1.7, there will need to be a maintenance release that contains only critical 1.6 defects and IE9 & FF4 browser support for 1.6.  All maintenance stream defects are also committed to 1.7 trunk.


Planned Release Content

“Async Loading, AMD Builds, Basic Mobile Controls, Visualization and IE9/FF4 Browsers”

The following content is being planned for Dojo 1.7.  For deferred content see below.

Core Library

AMD-aware Build Tools 

Owner(s): Rawld

There will be a new AMD-aware build tool for Dojo 1.7, which can optionally replace the current build tool which has been used from Dojo 1.0-1.6, for users that conform to the AMD module format introduced in Dojo 1.7.  This build tool will continue to produce JS and CSS-optimized layer builds of Dojo.  It is based on the BackDraft Build tool which was prototyped during the 1.6 release.

Note: this link is to a currently external (non-Dojo Foundation) “BackDraft” bdBuild tool docs.  Rawld has stated his intent is to integrate this into /util under Dojo ccla.

Asynchronous Loaders 

Owner(s): Rawld

The initial work started in Dojo 1.6 for support of asynchronously loading modules will be completed in Dojo 1.7, while the older synchronous and xdomain loading continues to remain an option through the Dojo 1.x release stream to maintain compatibility.

Note: this link is to a currently external (non-Dojo Foundation) “BackDraft” bdLoad docs.  Rawld has stated his intent is to integrate this into Dojo under Dojo ccla as the new asynch loader.  It’s the leading candidate for Async loader in 1.7, however other loader implementations can be used.

has() Branching

Owner(s): Rawld, Kris

Integrate has() branching for builds.  1.6 will integrate has() function into the build tool for more targeted builds.  

Whether has() will be exploited inside modules in 1.6 and whether has.js feature detection will be integrated is still being discussed.  

Update: we will likely has() enable _base in 1.7

Touch Specification 

Owner(s): Evan, Emmanuel

A unified touch API will be provided in Dojo core for touch events and gestures.  This implementation enables modules that need to respond to common touch events and gestures to do so in a consistent way that works across devices and desktop browser environments.

Update: This will likely be based on the has()-refactored events.js module.


Common UI Framework

Dijit/Mobile refactoring 

Owner(s): Doug, Bill, Kamiyama

Dijit has often taken a hit for being “too big” for mobile device use, largely due to the large number of widget features supported for desktop scenarios, and also due to the legacy of having to support many different desktop browsers and versions.

It is also important that websites designed for desktop browsers using 1.7 can be viewed and be fully functional wherever possible on mobile smartphones and tablets.  This means testing exiting dijit widgets to make sure they are still functional on mobile devices supported by 1.7--not that Dijit is being redesigned for mobile.

MVC for Dijit & Mobile  

Owner(s): Ed, Rahul

Across both desktop and mobile scenarios, it is important that it be extremely easy to create data-bound forms and views for typical UI patterns (master detail, repeats, two-list, etc.).  The infrastructure provided for doing this must fit well with Dijit’s existing design, and be usable both with the myriad legacy Dojo datastore implementations that have been written by customers, as well as work well with the new simpler Dojo Stateful APi.  In addition, it needs to be easier to be able to dynamically create forms that are based on back end data.

Mobile & Desktop UI

Mobile Widget Specification 

Owner(s): Kamiyama

Building on Dojo 1.6’s dojox.mobile view and layout functionality, in Dojo 1.7 we will complete the additional widgets & features necessary to have Dojo mobile be competitive.

Blackberrytm Mobile Theme & Custom Mobile Theme examples

Owner(s): Kamiyama

A new Blackberry theme has been added to Dojo Mobile.  As additional widgets are added to Dojo mobile, they will be themed to iOS, Android & Blackberry.  

All themes will be parameterized using Less.js similar to Claro desktop theme, to allow for easy customization.

Application Controller Library 

Owner(s): Dustin, Stephen

Dojox.mobile.app framework is being refactored under a new namespace, dojox.app.  The intent is to provide a new application controller library to define and run applications views, models and view to view transitions which works across both desktop and mobile scenarios and fits well with dojox.mvc (which deals with mvc concerns inside a view).


Graphics, Visualization & Mapping

GFX Enhancements for Mobile Scenarios

Owner(s): Eugene, Patrick

There are many enhancements to both Dojo GFX in order to optimize it to be used on both desktop and mobile devices with touch interaction.

Mobile Charting Enhancements -

Owner(s): Tom, Christophe

There are many enhancements to both Dojo GFX and existing charting modules in order to optimize them to be used on mobile devices with touch interaction.

Charting & Grid Gestures - Evan

Gauges Enhancements 

Owner(s): Tom, Emmanuel

Dojo’s Gauges are getting a face lift in Dojo 1.7, and are being optimized for use on both desktop and mobile scenarios.

Unified Geo Mapping API 

experimental

Owner(s): Tom, Marc

(Experimental for 1.7)

Maps are now a common part of many web applications, whether desktop or mobile.  A new unified API for geo mapping will be introduced in Dojo 1.7, which will allow multiple map provider implementations to be plugged in, which can use different rendering engines if necessary (future possibilities include: WebGL) to draw or render maps

Dojo OpenLayers Map Provider 

experimental

Owner(s): Marc

(Desktop only for 1.7)

An OpenLayers-based map provider implementation and corresponding map widget will be provided that is optimized for desktop browsers in Dojo 1.7.  Future dojo releases will focus on optimizing this map provider on mobile devices.

Gallery & Demos

Widget Gallery 

Owner(s): Stephen

A new mobile widget gallery is being developed for driving demos of the above features and other mobile features already introduced in Dojo 1.6.


Supported Browser Platforms

Desktop Browsers

Firefox 3.5, 3.6, 4.0

Safari 5

Chrome 11+

IE6, IE7, IE8, IE9 (Win7 only)

Opera 10.50 and later (Dojo core only)

Mobile Operating Systems (Dojo Core & Dojo Mobile only)

Safari for iOS 3.1+, 4.2+

Webkit for Android OS (2.1, 2.2, 3.0)

Blackberry 6 Bundle 695 default browser (experimental)

Marketing Improvements

During the 1.6 timeframe, new design work was done around the entire Dojo main website.  Videos have been shot,  tutorials have been created, and a vision for improving Dojo’s Visualzation, Widget  and Mobile-specific landing pages was outlined, to give us a roadmap for how the website can evolve through 2011 to give a better quality and overall message to potential consumers of Dojo.  This work will continue during the Dojo 1.7 release to ensure Dojo GA’s with a high quality marketing site around the above release content...not just a release note.


Dojo 1.7 Schedule

Milestone 1

14 Mar - 6 May

Iteration 4

14 Mar - 25 Mar

Iteration 5

28 Mar - 8 Apr

Iteration 6

11 Apr - 22 Apr

Iteration 7

25 Apr - 7 May (May 7 feature freeze)

Milestone 2 - Release Shutdown

9 May - 10 Jun

Beta 1

13 May

Beta 2

27 May

RC1

10 Jun

General Availability

20 Jun

Website Live

30 Jun

Process & Procedure Changes

Release Cycle Goal: 12 weeks

Alpha Development Phase (Milestone 1 - 6wks)

Gather Features for next Release

Talk to the core dojo committers and gather a set of features that will be included in the next release. Determine a timeline for the next release.  This step has already begun, see Planned Release Content above.

Announce Roadmap for next release

Write a blog post talking about the new features. Explain to the world why these features are important. If there are core changes coming explain what they are and what users would have to do to update their code for it. Tell the world the targeted milestone date. Update the document at plan.dojotoolkit.org (for 1.7 we’d put it at http://plan.dojotoolkit.org/documents/1) 

Talk it up

On two week intervals, we will gather from key contributors the status of new features. This will include demos and a summary for these features as well as writing short blog posts on the Dojo Toolkit website showing off the progress of the new features coming to the next release of Dojo.

Closing down the Release (Milestone 2 - 6wks)

During the cycle

We will release and publicize Betas and Release Candidates and make clear that after the beta and RC have expired they will not be supported. Any documentation provided around Betas and Release Candidates will be replaced with the final when the final release is made. The goal is to get people to try the new dojo with their existing code base and provide feedback during the cycle so that more bugs can be caught and so that upgrading can be a lot less painful.

Beta 1

Description: Feature complete

Duration: 2 weeks

  • Post the beta on the download page.
  • Get the Beta up on JSFiddle and similar sites.
  • Find a CDN that will accept our Beta(?)
  • Post the reference guide and API docs for the beta (this will be replaced by the final when it is released).
  • Duplicate the tutorials for the latest release and update them to work with the beta. Create tutorials for the new features.
  • Announce the beta on the DTK blog.
  • Encourage existing users to start testing their code with the latest dojo release beta.

Beta 2

Description: If required

Duration: 1 week

  • Post the beta on the download page.
  • Get the Beta up on JSFiddle and similar sites.
  • Find a CDN that will accept our Beta(?)
  • Announce the beta on the DTK blog.
  • Encourage existing users to start testing their code with the latest dojo release beta.

RC1 

Description: Release Candidate

Duration: 2 weeks

  • Post RC1 on the download page.
  • Get the RC up on JSFiddle and similar sites.
  • Find a CDN that will accept our RC(?)
  • Post the reference guide and API docs for the RC (this will replace the beta docs).
  • Duplicate the tutorials for the latest release and update them to work with the beta. Create tutorials for the new features.
  • Announce the beta on the DTK blog.
  • Encourage existing users to start testing their code with the latest dojo release beta.

RC2

Description: If Required

Duration: 1 week

  • Post RC2 on the download page.
  • Get the RC2 up on JSFiddle and similar sites.
  • Find a CDN that will accept our RC2(?)
  • Announce RC2 on the DTK blog.
  • Encourage existing users to start testing their code with the latest dojo release beta.

Release

Description: Finalize the release

Duration: 2 weeks

  • Get the code on CDNs, JSFiddle etc.
  • Post the final on the download page and update the site to reference the new version.
  • Update the tutorials to use the final release CDN.
  • Replace the beta API and Ref Guide with the final.
  • Announce the final on the DTK blog.
  • Encourage existing users to upgrade to the final.

Test Plan (TODO)

TBD - Chris - Working on Test strategy/plan.  We’ll just link to it here ref guide when it’s ready.

Karen: addition of QA into cycles - expectations of testing by owners, development of reusable test cases, code review; what types of bug fixes/code changes are acceptable at each type of release

Deferred Content

Packages & Plugins Specification 

Owner(s): Tom, Kris, Torrey

With the move toward version 2.0 and distributed code repositories, it will be soon possible to create modules that stand alone as individual projects that can be used with other CommonJS AMD compliant toolkits.  

The Packages & Plugins Specification describes the formal requirements that individual Dojo Foundation subprojects must follow to become Dojo Foundation santioned modules and candidates for inclusion in the main Dojo 2.0 distribution.

Reason deferred: Needs more time on distributed repository issues.  We need to try this out in conjunction with package manager for some apps and refine the approach.  Proposal is to try modifying demos apps to follow this specification in 1.7 and learn from that effort.

Package Repository & Manager 

Owner(s): Kris

A new package manager command line tool will pull together packages which following the Packages & Plugins Specification that are distributed in different locations on the internet together into a local workspace using the Package Repository metadata to determine what is aggregated.

Reason deferred: Same as Packages Specification above.  We may be able to get an experimental version of the package manager ready in 1.7 timeframe to get field experience/feedback.

Grid 

Owner(s): Evan, Kris, Noguchi

(Desktop only for 1.7)

The Grid and it’s plugin infrastructure has been completely refactored into a new lightweight implementation.  In 1.7 timeframe, initial headway was made to provide the new Core Grid API, Cache API and a Grid controller API along with a set of plugins which can enable additional features only when needed.  However, to eliminate customer confusion with the other numerous grids, this work will remain separate in GitHub until 1.8.  We are now working on integrating other previous AMD-based lightweight grid efforts on top of this core, to deliver a new Grid for 1.8 which can be used in both Desktop and Mobile scenarios.  A plan must be developed as part of 1.8 release which clearly communicates the migration path off of pre-1.8 grid’s and onto the new replacement, which needs to include a deprecation plan for the existing 1.7 grid components/api’s.