I'm happy to announce the first and hopefully last release candidate (zip) for Dojo 0.4.2. As usual, you can grab your favorite builds from download.dojotoolkit.org. 0.4.2 is a minor patch release to address the most severe issues and regressions in 0.4.1. Unlike 0.4.1, there are few if any new features. We encourage adventurous users of 0.4.1 to try the release candidate and give us feedback. The final 0.4.2 release is tentatively scheduled for two weeks from now. While 0.4.2 doesn't include new features, the build system has changed significantly thanks to the hard work of James Burke from AOL. It now supports cross-domain builds even better and a new sub-domain, build.dojotoolkit.org, has been setup to support a brand-new web-based build tool. The 0.4.2rc1 build page is up and it includes details on how to use the simple x-domain inclusion script that we're maintaining for all new releases. Significant work has gone into 0.4.2 to ensure that x-domain builds work correctly and the new web-based build tool will let you easily generate a new dojo.js file to optimize your deployments without ever needing to download the "source" of Dojo or learn how to use Ant. I'm tremendously excited about this.

Beyond 0.4.x: 0.9 and 1.0

Work continues on ensuring that 0.4.2 is the highest quality Dojo release to date, but major changes have also been quietly taking place. At last month's 3D2 significant decisions were made about how to evolve the toolkit. First, Dojo 1.0 will ship this year. Secondly, we will be splitting the project up into 3 separate but coordinated efforts: dojo core, dijit, and dojox. Lastly, it was decided that a major backwards incompatible jump will be made for the next major release of Dojo. To date, we have always attempted to provide at least one full point revision's warning regarding APIs that were changing or being removed. This policy has allowed attentive users to easily stay abreast of porting their applications between Dojo versions but it has also contributed significant cruft to the core of the toolkit. This cruft will be removed wholesale in the next major revision, Dojo 0.9. No in-code deprecation warnings will be provided. Instead, a full and complete porting guide for 0.4.x users will be created. The extent of the planned changes make back-compat shims unrealistic. In the coming weeks we will be outlining the details of the project split, but the major outlines of how to proceed have been decided and are already under way. The first part of the plan involves restructuring the Dojo subversion repository to represent the three major projects. The roles and responsibilities of these projects and their leads are also being clarified:

1. dojo core will consist of a tightly constrained set of lower-level APIs that make JavaScript better as a language and make DOM manipulation easier. All code in the core (and its widget-focused sister project, dijit) will be required to meet stringent quality, testing, and documentation standards. Most of the code currently in Dojo's utility namespaces is being pored over and most will be either discarded outright or moved to dojox. The resulting core will be very lean, stable, and fast. I will continue to be the project lead for the core effort.
2. dijit is the new home for the "official" widget set. Not all of the current widgets will make the cut for Dijit and only those that are accessible, internationalized, themed, tuned for performance, and agreed to be generally useful will be part of Dijit. The widget system is being significantly streamlined to support this effort. APIs for base widgets are being rationalized, the inheritance hierarchy drastically simplified, and the page parsing infrastructure scrapped in favor of a much higher performance approach demoed at 3D2. Bill Keese, the uber-capable and dedicated module owner for the widget system, will become project lead for Dijit.
3. dojox will carry on Dojo's strong tradition of invention. Many of the most important Dojo modules push the edges of what's possible and have helped to bring the theoretical into the plausible over the last 2 years they will be allowed to thrive in dojox without the restrictions placed on core and Dijit code. Dojox will impose fewer restrictions and regulations on projects developed there. Far from being a second-class code ghetto, dojox will be home to important modules like dojo.storage, dojo.gfx, and dojo.charting.

No matter what project a module "lives" in, the entire spectrum of modules will continue to be available from an evolved version of the new web-based build tool. I know this post has run long, and so I'll finish with a brief word on timing and leave the inevitable slew of questions for discussion on dojo-interest and to follow-up blog posts. In the next several weeks we expect to have a solid first draft of the 0.9 API specification for the Core. Based on that and progress in porting widgets to Dijit and migrating code to dojox, milestone releases will be made available for the adeventurous starting sometime in March. The current plan, subject to some play in the joints, is for an alpha release of 0.9 in late spring, a beta shortly thereafter, and 0.9 final in early to mid summer. From 0.9 to 1.0 we are targeting testing, completeness, and few if any API changes in the Core and Dijit. Dojo 1.0 will be available in late summer or fall of this year.