Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@jakarta.apache.org Received: (qmail 73557 invoked by uid 500); 23 Apr 2001 16:36:09 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Reply-To: "Avalon Development" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 73136 invoked by uid 500); 23 Apr 2001 16:35:55 -0000 Delivered-To: apmail-jakarta-avalon-cvs@apache.org Date: 23 Apr 2001 16:35:29 -0000 Message-ID: <20010423163529.72249.qmail@apache.org> From: bloritsch@apache.org To: jakarta-avalon-cvs@apache.org Subject: cvs commit: jakarta-avalon Avalon-4.0-RELEASE-PLAN bloritsch 01/04/23 09:35:28 Added: . Avalon-4.0-RELEASE-PLAN Log: First proposed Release Plan Revision Changes Path 1.1 jakarta-avalon/Avalon-4.0-RELEASE-PLAN Index: Avalon-4.0-RELEASE-PLAN =================================================================== NOTE: This document is a draft of a release plan for the next major release of the Avalon Framework. Nothing in this document should be considered authoritative until it has been discussed and approved on the AVALON-DEV mailing list. Avalon Framework 4.0 Release Plan ================================= Objective: The objective of the proposed Avalon Framework release is to provide a stable API for users of the Avalon Framework and to provide a small number of highly reusable components to speed development efforts using the framework. Changes (to Avalon 3.x): Avalon 4.0 will repackage all the core interfaces and default implemenations into a logical heirarchy as opposed to one monolithic package. Avalon 4.0 will also remove untested and unusable components from the release and place them in a white- board area. Avalon 4.0-beta 1 Release: Code Freeze/Tag Criteria: * All interfaces and implementations in agreed upon final resting place. * Excalibur Components evaluated as stable/necessary have API finalized and made stable. Release Manager: Berin Loritsch To help ensure widespread testing, this build must include an acceptably simple way of running the internal Avalon tests through Ant. To this end, the Excalibur components included in the release must have a test suite that is executable by the Avalon test framework. The build will separate the test jar and the release jar so that the test classes are not included in the release. After release of beta 1, work will start on bug fixing and other changes as required by the release criteria. Avalon 4.0-beta 2 Release: Code Freeze/Tag Criteria: * All interfaces fully documented and contracts explicitly declared in JavaDocs and xdocs. * All Excalibur Components must be documented and contracts explicitly declared in JavaDocs and xdocs. * All identified bugs from beta 1 must be resolved. Release Manager: Berin Loritsch This release will fine tune the tests with regression tests for bugs discovered in the beta 1 release. After release of beta 2, work will start on bug fixing and other changes as required by the release criteria. The API will be audited to make sure that the Javadocs are consistent with the xdocs. Avalon 4.0 Final Release: Code Freeze/Tag Date: 1 month after Beta 2 Release Manager: Berin Loritsch This release will fine tune the tests with regression tests for bugs discovered in the beta 2 release. No showstoppers can be allowed in this release. No known bugs can be included in the final release. Additional Release Criteria =========================== The standards of quality and testing in Avalon 4.0 will be significantly higher than in previous releases. 1) All testing framework must test for regression and known bugs to the release date. 2) Open bugs should be fixed. 3) The Avalon framework must be tested with existing, complex applications (Cocoon, JAMES, etc.). 4) Any changes to the core API must be aggreed upon and not taken lightly. Platforms: We must make sure that Avalon test reports (at least self-test) contributed by developers and users exists for at least Linux, Windows NT/2000, and Solaris (if possible). JDK We must test Avalon with JDK 1.2.2 and higher. When JDK 1.3+ is availably for *BSD unices, we will evaluate whether we enforce JDK 1.3 as the minimum at that time. Maintenance Plan ================ The release team must consist of at least 3 people, and will fix any major bugs that will be found after the 4.0 release, and propose to the group minor releases, if absolutely needed (security/stability/ contract violation bugs). No backward-incompatible or major changes should be made. Bug Fix releases will only increment the micro version number (i.e. 4.0.1, 4.0.2, etc.). Feature additions (excalibur components) must be agreed upon by all developers, and API and documentation finalized before being incorporated into a release. At this point the release will increment the minor number (4.1, 4.2, etc.). The release team must coordinate the maintenance and support of Avalon Framework, 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. --------------------------------------------------------------------- To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: avalon-dev-help@jakarta.apache.org