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 Beta: Code Freeze/Tag Date: March 15, 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. Tomcat 3.3 Addition Betas: Code Freeze/Tag Date: Weekly from March 15, 2001 Release Manager: Larry Isaacs After the first beta, we will periodically build beta releases in order to track the evolution. Tomcat 3.3 Final Release Code Freeze Date: Apr 5, 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. 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.