NOTE: This is outdated information that applies only to Tapestry 4.1. For the current Tapestry roadmap see http://tapestry.apache.org/introduction.html#Introduction-Roadmap
Tapestry 4.0 had a very (too) long release cycle. New committers came (and, unfortunately, went) and the frayed edges of the process became manifest towards the end of the cycle.
Tapestry 4.0's release cycle has clearly shown the limitations of Tapestry's release numbering system. Other projects have benefited from a numbering scheme that doesn't not explicitly identify alpha/beta/rc status, since that status is voted upon after the release has been produced.
To merge into the Apache and Open Source mainstream, Tapestry numbering shall change; the first 4.1 release will be 4.1.1 (not 4.1-alpha-1). Once the code changes are reasonably stable, an existing release will be voted in as the first beta release (it may be, say, 4.1.7). Further beta releases will follow. Eventually a stable beta release can be voted as the final 4.1 release (say, 4.1.12).
Tapestry 4.0's home grown, Ant based build environment has been a growing issue. While lean, and mean, it is too difficult for end users to set up, and typically required the users download the source to HiveMind and Forrest as well. Currently (Jan 2006), HiveMind 1.2 is being converted to build using Maven 2.0. Once that is successful, a conversion of Tapestry to Maven 2.0 will occur as well.
Having an easily built framework will reduce the need for frequent releases, as it will be a simple, standard process for anyone to download latest source from Subversion and build locally.
The focus of this milestone will be on refactoring the various Asset services in order to provider richer support for a more natural development style in relation to the Shell and asset inclusion logic.
Component Identities/Rewind Cycle/URL rewriting
A much more impactual and overarching change to the framework will hopefully result in a unified system for identifying and dealing directly with components, as well as improving overall handling of form input field value parsing. These changes will result in a number of great improvements, the least of which will allow a very dynamic and intuitive request cycle for handling ajax style logic.
The current Form and validation framework provides a lot of nice functionality, this milestone will hopefully finish up some of the work started here to provide an even more intuitive means of dealing with forms / form submissions / and validation of input values.
- Eliminate translator: The translator binding is needed, but it is hoped that the type of values being validated can be inferred automatically from the existing environment, filling the last major chink in the armor of form support that creates a lot of confusion around the validation system.
With the other three milestones completed it should finally be possible to start incorporating some of the framework feature enhancements into the existing tapestry components to bring them more up to date with current web standards.
Integration Testing Framework
Tapestry has had an internal integration framework for some time now, but it has never been "productized". A new or revised integration framework is a necessity for Tapestry 4.1.
HowardLewisShip: I've been thinking about using jWebUnit, but replacing the guts somehow to send requests to a simulated servlet container.