$Id: status.xml,v 1.31 2003/06/07 18:42:06 husted Exp $

This document outlines some of changes we expect to see in future releases of Struts.

This document is provided for discussion purposes only. All releases and changes to the codebase are subject to a vote of the Struts Committers.

The Struts development teams uses the Apache Bug Database (Bugzilla) to manage problem reports and enhancement requests. For your convenience, here are some common Bugzilla queries:

• Open reports
• Open problem reports
• Open enhancement requests
• Reports to be handled "LATER"

Struts 1.1 provides a number of functional enhancements, including support for application modules. Other enhancements include action-based authentication, use of Commons- Datasource and Commons-Logging packages, declarative exception handling, Dynabean support, Plug-In classes, and a pluggable request processor. Several extensions are now bundled with the Struts distribution, including the Nested taglib, Tiles, and the Commons Validator. An optional Struts-el taglib makes it easy to use Struts with JSTL. Backward-compatiblity with Struts 1.0.x is a primary goal of this release.

Struts 1.1 Release Candidate 1 is in circulation and we are working toward a final release.

Struts 1.2.x will include additional functional enhancements along the same lines as Struts 1.1. The platform requirements will remain the same (Servlet 2.2 / JSP 1.1). The release will focus on refactoring of existing functionality, with a continued emphasis on backward compatibility.

The Struts 1.2.x series is expected to incorporate several incremental releases (in contrast to Struts 1.1).

Enhancements are logged in Bugzilla as LATER or REMIND tickets as they are suggested. Enhancements that represent incremental improvements are now being tagged for the "Struts 1.2 family" milestone. When developers are actually working on an enhancement, they should re-tag it for a specific release milestone, such as "1.2.1" or "1.2.2". Future release milestones are provided for enhancements which are being actively planned or developed but may not be ready for the very next release.

The listing of an enhancement in Bugzilla does not imply that is being "planned", merely that it is under consideration. If a listing has not been tagged for a specific milestone by a working developer, then it may never be realized.

If an enhancement has not been tagged for a specific target, feel free to start working on it yourself. Many of our best features have been contributed by developers, just like you. If you would like to announce your active interest in an enhancement, please post a note on the ticket, and tag it to an appropriate release milestone.

Struts 2.0.x will include broader enhancements. The implementation will expect a minimum platform of Servlet 2.3 / JSP 1.2 and refactorings may include the use of Filters. It is expected that Struts 2.0.x will rely on JSTL and the JavaServer Faces API as supporting technologies. However, the focus of the Struts framework will remain on the Controller aspect of a Model 2/MVC architecture. The core framework will continue to be both Model and View independent.

Target features include:

• Refactoring for Filters and other new technologies
• Direct support for JSTL/JSF taglibs and the JSF API
• Better support for other presentation layers, such as XLST (as in 1.2.x)
• Comprehensive unit tests (as in 1.2.x)

Development of Struts 2.0 will include taking a completely fresh look at the architecture. The goal for 2.0 will be to incorporate everything we've learned in the past years of Struts usage, and create something even better.

Of course, it is anticipated that the Struts team will continue to support 1.x users for a long time with bugfixes and incremental enhancements.

• Release Plan 1.1-rc2
• struts-faces taglib
• Workflow Proposal

A point release should be made before and after any product change that is not a "fully-compatible change" (see link). This includes moving a dependency from an internal package to an external product, including products distributed through the Jakarta Commons. We should place any fully-compatible changes in the hands of the community before starting on a change that is only "interface" or "external-interface" compatible.

A fully-compatible point release does not always need a "preview" beta or milestone release. If appropriate, a Release Candidate can be cut, uploaded to the Release Manager's home directory on cvs.apache.org (~/public_html), and voted to be released to the general public from there.

Any release should follow the same general process used by the Jakarta Commons and the Apache HTTP Server project.

• Releasing Common Components
• Signing a release version
  • The MD5 tool is installed on daedalus, and you can create the digests for Struts releases there.
• Apache HTTD Server Release Guidelines

Additional remarks:

• The release process can seem daunting when you review it for the first time. But, essentially, it breaks down into three phases of just a few steps each:
  • Building - Bugzilla, dependencies, release notes, JAR manifest, licenses, copyrights, and build (using the release target).
  • Testing - JUnit, Cactus, web apps (for all "supported" containers).
  • Distributing - Checksum, sign, mirror, release, update Struts site, update Jakarta site, announce.
• Our dependencies on external JARs (including Commons JARs) should be in line with our own release status. Our nightly build can be dependant on another nightly build. Our beta can be dependant on another beta, but should avoid a dependance on a nightly build. Our release candidate can have a dependance on another RC, but should not have a dependance on a beta (and certainly not a nightly build). Our final release can only have dependencies on other final releases.
• Use your own discretion as to detail needed by the Release Notes. A high-level description of the changes is more important than providing uninterpreted detail. At a minimum, new features and deprecations should be summarized, since these are commonly asked questions. Ideally, the release notes should be maintained continuously for the nightly build so that we do not need to quickly assembled them on the eve of a Release.
• Test building the distribution under prior version of J2SE, if possible, to ensure that we are still backwardly-compatible. But, our Release distribution should be built using the latest release of J2SE, to take advantage of all available compiler enhancements.
• Before building the final release, run the JUnit and Cactus tests using the same configuration used that will be used to build the Release distribution.
• There is a "release" target in the buildfile that will zip and tar the releases. Before uploading the release, extract the sample web applications and deploy the WARs under each of the "supported" containers. Play test each application under each container to be sure they operate nominally.
• By the way, the nightly builds are being created on a machine of Craig McClanahan's. If there are problems with a nightly build that seem infrastructure related, Craig is the one to contact.

Source code and documentation contributed to the Struts repositories should observe the:

• Jakarta project guidelines,
• Elements of Java Style, and
• How to write Doc Comments

as core references regarding the formatting of code and documentation.

Clarifications

• First, "Observe the style of the original". Resist the temptation to make stylistic changes for their own sake. But, if you must reformat code, commit style changes separately from code changes. Either change the style, commit, and then change the code, or vice- versa.
• Set editors to replace tabs with spaces, and do not trim trailing spaces.
• Specify imported classes (do not use .*).
• Write all if/else statements as full blocks with each clause within braces, unless the entire statement fits on the same line.
• Use :FIXME: and :TODO: tokens to mark follow up notes in code. You may also include your Apache username and the date. :FIXME: we need to do this sometime (husted 2002-11-14)
• Use @since to document changes between Struts versions, as in @since Struts 1.1.
• Wrap lines of code and JavaDoc at column 78. You can include a "comment rule" in the source to help with this.
  // ------------------------------------------------------------------------ 78
• Please do your best to provide high-quality JavaDocs for all source code elements. Package overviews (aka "Developer Guides") are also encouraged.
• When working on a bugfix, please first write a JUnit test that proves the bug exists, and then use the test to prove the bug is fixed. =:0)
• When working on an enhancement, please feel free to use test-driven design and write the test first <head-slap/>. For more about TDD, see the MockObjects project .
• As files are updated from year to year, the copyright on each file should be extended to include the current year. You do not need to change the copyright year unless you change the file. Every source file should include the current Apache License and copyright.
• Provide high-level API compatibility for any changes made within the same major release series (#.x). Changes which adversely affect compatibility should be slotted for the next major release series (++#.x).
• Our favorite books about programming are Design Patterns and Refactoring.
• Our favorite book about open source development is the The Cathedral and the Bazaar.
• Our favorite science fiction author is Robert Heinlein. TANSTAAFL.
  (Except on Friday, when we favor Douglas Adams. SLATFATF.)

Next: Struts User Guide

Website updated from CVS: 2003 MAR 18 by husted.

Javadocs updated from CVS: 2003 FEB 15 by husted.