NOTE: This document is a draft of a release plan for the next dot release of Tomcat. Nothing in this document should be considered authoritative until it has been discussed and approved on the TOMCAT-DEV mailing list. Tomcat 3.3 Release Plan ======================= Objective: The objective of the proposed 3.3 release is to complete the development of jakarta-tomcat 3.x and achieve the stated goals of providing a production quality 2.2/1.1 servlet container. Changes: Tomcat 3.3 will implement no new major features compared with 3.2. Some tuning and improvements are made to various modules to increase the usability and flexibility. The STATUS.HTML document summarizes some of these changes in the action items marked for the 3.3 release. The "changes3.3" document provides a more detailed list of the code changes. Most of the changes are related with continuing the refactoring of the 3.x and performance enhancements that couldn't make it into 3.2. Tomcat 3.3 Milestone 1 Release: Code Freeze/Tag Date: Feb 8, 2001 Release Manager: Larry Isaacs To help insure widespread testing, this build must include an acceptably simple way of running the internal Tomcat tests and Watchdog in some form. The build must pass all watchdog and all existing test suites. It should work on both JDK1.1 and JDK1.2. After the build of Milestone 1, work should start in reviewing all the classes and interfaces in tomcat.core, and any feedback should be discussed and incorporated. Also, the documentation will be reviewed and improved. In parallel, work will start on fixing all bugs and making other changes as required by the Release criteria given below. This work will continue during the beta period. Whenever possible, we should try to create a self-test case ( using the current self-test application and GTest ). It is desirable to add more documentation on running GTest and the test application, to simplify the testing work. We must test and make sure that JspServlet still function properly. Tomcat 3.3 Milestone 2 Release: Code Freeze/Tag Date: March 1, 2001 Release Manager: Larry Isaacs This release is optional depending on the amount of bug fixing that occurs since the milestone 1 release. The major goal of the week following milestone 1 will be to identify what further work is needed based on the feedback. During this time it is hoped that there will be enough bug fixes and tests added to make this release worthwhile. Should that not be the case, this release may be skipped since the beta release is expected a week later. Tomcat 3.3 Milestone 3 Release: Code Freeze/Tag Date: May 12, 2001 Release Manager: Larry Isaacs Known issues in order of priority 1. Verify that JSP source is not served when escaping tricks are used 2. Update build process to create archives and internal directory structure consistent with other Jakarta projects, i.e. use jakarta-tomcat-3.3-xxx. Tomcat 3.3 Milestone 4 Release: Code Freeze/Tag Date: June 20, 2001 Release Manager: Larry Isaacs This release contains a switch to using jakarta-tomcat-connectors for some utility classes. It also uses jakarta-tomcat-jasper for building jasper34, which will be enabled as the default JSP handler. The internal "jasper33" will be enabled as the default JSP handler for future releases of Tomcat 3.3. Known issues in order of priority: 1. Jasper34 needs to be stable. 2. Watchdog and internal test need to be passing all tests. 3. Build documentation need to be updated to document new dependencies on jakarta-tomcat-connectors and jakarta-tomcat-jasper. Tomcat 3.3 Beta 1: Code Freeze/Tag Date: July 11, 2001 Release Manager: Larry Isaacs No major change will be done after the Beta is build without a vote. The release team can reject any change they feel is too big and can introduce regressions, or is not needed. No major bug ( spec compliance or stability ) should be open in order to enter beta. During the beta period we will fix all remaining bugs and run the manual tests for the bugs that have no automated test case. Known issues in order of priority: 1. Port all missing updates to Jasper from Tomcat 3.2.2 and verify that all Jasper theading issues are dealt with. This includes Bugzilla Bugs 80,140,1039,1123,1280,1646 2. Check HttpSessionFacade for spec compliance. Know problems: A. setAttribute() calls valueBound() after storing the object in the session. The spec calls for the reverse. B. setAttribute() doesn't call valueUnbound() for the object it replaces, if present. 3. Fix getResource() to not allow access to files outside of the web application. 4. Session recyling includes keeping the HttpSessionFacade. I believe this represents a security risk. May need to discard session facades, or at least discard them for untrusted web applications. 5. getRequestURI() should return an encoded string 6. Update getRemoteHost() to be consistent with Tomcat 3.2.2, which does a reverse DNS lookup. 7. Verify no reqressions. 8. TBD... Tomcat 3.3 Beta 2: Code Freeze/Tag Date: July 18, 2001 Release Manager: Larry Isaacs This release should fix any major bugs found in the prior beta and any missed regressions. Known issues in order of priority: 1. TBD... Tomcat 3.3 Final Release Code Freeze Date: August 1, 2001 Release Manager: Larry Isaacs The final build. The pre-requisite for the release is having no bugs in the test suite, resolution for all known bugs and approval by the community. Known issues in order of priority: 1. Update/fix documentation as much as possible Bugs That Won't Be Fixed In Tomcat 3.3 The following Bugzilla Bugs are known issues that are not planned to be addressed in Tomcat 3.3. Bug #75: Translation time attribute evaluation not provided to TagExtraInfo class Bug #143: Tag handlers with properties of type "Object" Bug #155: Quick Blurb saying "Everything is initialized" Bug #164: IIS Logging Bug #203: `tomcat.sh env` ruins the shell if $TOMCAT_HOME is not set Bug #451: ServletException displaying wrong lines in debug information Bug #481: Misleading exception report Bug #524: Can't use Apache SSI with mod_jserv Bug #631: RequestDispatcher.include output is in wrong order Bug #1057: Context Paths and numerals. Bug #1433: Comments are parsed inside tag. Release criteria ================ The standards of quality and testing will be significantly higher than in previous releases. 1. Tomcat 3.3 should have no regression compared with 3.2. Any reported regression is a show-stopper and a release can't be made before it is resolved. 2. Open bugs should be fixed, if possible. 3. Tomcat 3.3 should be tested with existing, complex applications ( cocoon, bugrat, etc ). 4. Jasper must include bug fixes that were done in both 3.2.x and 4.0, and various enhancements that are deemed appropriate. 5. All bugs that have been opened after the Tomcat 3.2.1 release will be resolved before a 3.3 release is made. "Resolved" means that one of the "resolutions" supported by BugZilla has been assigned to the bug. 6. Full review of the code, making sure the modularity and extensibility goals have been achieved. 7. Make sure that the refactoring is clean, and maintenance will be easier that 3.2 8. Ensure that the performance is (significantly) better than 3.2 9. Ensure that Jasper is compatible (as much as possible) with the version used in the proposed 4.0. This refers to behavior differences outside of the JSP spec, which could create problems moving a web application from Tomcat 3.3 to Tomcat 4.x. Platforms. We must make sure that tomcat test reports ( at least watchdog + self-test ) contributed by developers and users exists for at least Linux, Solaris, Windows 9x, Windows NT/2000. It is desirable to have test reports on MacOS 9/X, FreeBSD. JDK. We must test tomcat with at least JDK1.1 and Java2 (multiple versions if possible) . The tests should also include a stress test ( a high load "ab" running for a long time ) Configurations Tomcat must be tested standalone, with Apache 1.3, Apache 2.0 and ( possibly ) with IIS and NES ( low priority ). Maintenance Plan ================= The release team must consist of at least 3 people, and will fix any major bugs that will be found after the 3.3 release, and propose to the group minor releases, if absolutely needed ( security or stability bugs ). In any case, no backward-incompatible or major changes should be made. The release team must coordinate the maintenance and support of tomcat, dispatching bugs and user requests to developers and acting as the last resort in resolving major support issues. Release Team ============ The release team will be composed of the committers that give the binding +1 on the release plan and release proposal. It must have at least 3 members, and follow the rules that will be established. The release team will coordinate the execution of the release plan, dispatch bugs to volunteers, review commits, and act as a lead in the release process. One of the team members will act as "Release Manager" and will be responsible for building the milestones, making the announcements about the release progress and all other roles that will be set by PMC and committers.