Hi everyone,
I’m Colin, one of the release managers for Dojo 1.8. Today I wanted to talk publicly about the planned roadmap and our focus for the next major release of Dojo.
Near the end of January, a group of team members held a meeting to discuss our direction for 1.8. The discussion was a little larger than simply the 1.8 release and cut across a few different areas, but we did establish a reasonable release roadmap full of new features and enhancements. For the most part, Dojo 1.8 will have a much more tightly controlled scope than 1.7, and we’ll be keeping release blocking issues reserved for Dojo and Dijit packages (instead of DojoX packages) in order to ensure a more reasonable/sprightly release cycle than the previous two.
Briefly, the list of planned improvements for 1.8 are:
- New standalone Router component
- New I/O component (to replace the existing XHR module)
- New calendar UI component
- New documentation parser
- Touch & HTML5 support for Dojo DnD
- Unified Touch API for Dijit, Dojo Mobile, and graphical modules
- More mobile widgets and general mobile support improvements, including the start of convergence between Dojo Mobile and Wink Toolkit
- Better SVG and Canvas support in
dojox.gfx
- Improvements to
dojox.app lifecycle management
- Improvements to data binding in
dojox.mvc
- More application demos
- More has-bracketing for feature detection and smaller builds
- Bug fixes for CLDR generation, AMD conversions, and more
In addition to code improvements, some very important additional changes are being made during the 1.8 release cycle:
1. Documentation
Everyone agrees: where to find correct and accurate documentation remains confusing to end-users and we need to work on improving this. From a tooling perspective, it was decided that the best route forward here is going to be to focus on getting a new JS-based documentation parser up and running as soon as possible, both so it can be used to generate the correct documentation for the API browser, and also so that it can be used to provide reports about what areas of code are missing documentation. Rawld Gill and Colin Snover will be the primary people working on this piece, but as they are both busy, anyone interested in the fun and exciting world of parsing should volunteer to help (even if it is simply running code against it until it breaks and lodging bug reports in the issue tracker on GitHub). Longer-term, the plan is to try to combine API & ref guide as much as possible to provide a *single* point of authoritative documentation for any given component.
In addition to tooling, we are working on improving user feedback during this cycle in order to try to learn where we need to focus our documentation improvements the most. Links have already been added to the bottoms of the API browser, tutorials, and reference guide pages so users can submit feedback about pages that are not giving them the information they need. We encourage everyone to use these links to provide documentation feedback.
Finally, Dylan Schiemann will be helping to set up some targeted documentation sprints to improve the quality and availability of documentation. More on this at a later date.
2. Browser compatibility
There are some new components slated for development during the 1.8 cycle that are dropping support for old browser versions (IE6 and Firefox 3.6). These components are likely to be the first to be referenced from external repositories as part of the move toward independent repositories for DojoX projects. Since we are still committed to continuing support for a wide range of browsers and browser versions within officially supported code, we will be implementing browser support grading in 1.8 (a la YUI and others) to make it clearer to end-users what kind of support they can expect for a given platform (and to enable us to more gradually phase out support for these legacy browsers).
We also understand that users don’t want to be stuck on a toolkit upgrade treadmill, but still need their products to be able to support new browsers as they are released. As such, we are currently evaluating a proposal to perform quarterly backports of browser support fixes from trunk to Dojo 1.5 and newer to assure end-users that their products will be able to support newer browser releases for a reasonable period of time. The release of Dojo 1.5.2 was a trial step in this direction.
3. Bug tracker
Our bug tracker has not been meeting our needs effectively when it comes to managing releases and issues. As such, new plugins have been introduced to improve this tool. We are also planning on going through and aggressively reducing the number of open tickets in order to provide a more realistic and manageable look at what work needs to be done for 1.8 and beyond.
As mentioned in the roadmap, our planned feature freeze date is April 16, with final release hopefully occurring sometime in early June. Keep your eyes here for updates and some sneak peeks at what’s coming up in the new release!
