DOJO TOOLKIT 1.7 RElEASE Plan & 2011 Roadmap (DRAFT) |
Blackberrytm Mobile Theme & Custom Mobile Theme examples
Application Controller Library
GFX Enhancements for Mobile Scenarios
Mobile Charting Enhancements -
Mobile Operating Systems (Dojo Core & Dojo Mobile only)
Alpha Development Phase (Milestone 1 - 6wks)
Closing down the Release (Milestone 2 - 6wks)
Packages & Plugins Specification
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.
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.
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. |
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.
“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.
AMD-aware Build ToolsOwner(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 LoadersOwner(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() BranchingOwner(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 SpecificationOwner(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 refactoringOwner(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 & MobileOwner(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 SpecificationOwner(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 examplesOwner(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. |
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 & MappingGFX Enhancements for Mobile ScenariosOwner(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 EnhancementsOwner(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 APIexperimental 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 Providerexperimental 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. |
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.
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)
Safari for iOS 3.1+, 4.2+
Webkit for Android OS (2.1, 2.2, 3.0)
Blackberry 6 Bundle 695 default browser (experimental)
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.
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 |
Release Cycle Goal: 12 weeks
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.
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 |
|
Beta 2 Description: If required Duration: 1 week |
|
RC1 Description: Release Candidate Duration: 2 weeks |
|
RC2 Description: If Required Duration: 1 week |
|
Release Description: Finalize the release Duration: 2 weeks |
|
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
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.
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.
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.