 |
Home | Changes | Index | Search | Go
This document outlines a strategy for providing downloadable releases of
SwingLab's Swing Extensions project, defining release
structure and release types, including the criteria used to determine if a
particular build is suitable to be released as a given type.
Note: For now, this is copied from SwingLabs forum post authored by Amy Fowler, 29.Sept. 2005. It's slightly edited to adjust for the current state of affairs. Future decisions should be reflected here.
For all release types issues refers to tracker types DEFECT, TASK, and PATCH. The ENHANCEMENT and FEATURE tracker items are not considered issues. There may be P1 or P2 enhancements or features in the tracker, such items do not affect the viability of a release.
Release Types
Development Builds
"Latest"
Intended to give developers access to "latest" bits without having to access cvs; not intended for developers unfamiliar with the project. Posted once per week, labeled with date and build number. {*** should we accumulate or only post the "latest? **}
Release Criteria
- Source builds cleanly
- All automated JUnit tests pass
"Milestone"
Intended to provide developers with stable snapshots of functionality
as its developed; doesn't have to be functionally complete, but what
is there should work without critical bugs. Labeled with ".X" release
number (e.g. "Milestone Release 0.8")
Release Criteria
- Source builds cleanly
- All automated JUnit tests pass
- All demos and interactive tests run successfully according to a defined script of basic actions which exercise key features
- No open P1 issues
- Open P2 issues documented in release notes
Project Releases
"Beta"
Intended to provide developers with an initial implementation of
all required features so that they may provide feedback on the design
and implementation; the release must include enough
documentation to enable a developer unfamiliar with the project to
use key features of the library. If feedback on a Beta release drives
substantial change in the API, then another Beta should be released
(e.g. "Beta2").
Release Criteria
- Source builds cleanly
- All required features are implemented in API
- At least 65% JUnit test coverage of all public API
- All automated JUnit tests pass
- All demos and interactive tests run successfully according to a defined script of basic actions which exercise key features
- No open P1 issues
- Open P2 issues documented in release notes
- At least 65% javadoc coverage with no javadoc warnings/errors
- Javadoc for all major components and features include simple usage examples
"Release Candidate (RC)"
Intended to provide developers with a high quality implementation of
the library to test for any serious undiscovered problems; the release
must include enough documentation to enable a developer unfamiliar
with the project to use all major features of the library. If no major
issues are discovered in an RC release, then it may be re-badged as
"final" (the ultimate goal of the RC).
Release Criteria
- Source builds cleanly
- All required features are implemented in API
- There have been no major API changes since last Beta release.
- At least 80% JUnit test coverage of all public API
- All automated JUnit tests pass
- All demos and interactive tests run successfully according to a defined script of basic actions which exercise key features
- No open P1 or P2 issues
- At least 80% javadoc coverage with no javadoc warnings/errors
- Javadoc for all major components and features include simple usage examples 9. Includes demo application which demonstrates how to combine key features together.
"Final"
Intended to provide developers with a high quality implementation of
the library that may be used to construct Java GUI applications.
Will be labeled with a major release number (e.g. "1.0").
Release Criteria
- Source builds cleanly
- All required features are implemented in API
- The last RC release has been available for at least 30 days with no new P1 issues reported.
- 80% JUnit test coverage of all public API
- All automated JUnit tests pass
- All demos and interactive tests run successfully according to a defined script of basic actions which exercise key features
- No open P1 or P2 issues
- 80% javadoc coverage with no javadoc warnings/errors
- Javadoc for all major components and features include simple usage examples
- Includes demo application which demonstrates how to combine key features together.
Release Structure
(this section most probably is outdated ... todo: update to current)
Each release will include the library jars, demos, and documentation
{*** should we include source? design-time jars with beaninfo? ***}
The zip file will have the following structure:
- README.html - provides overview of content, pointers to other docs, and instructions for running the demos
- ReleaseNotes.html - documents critical fixes, api changes, and known issues
- swingx.jar - library jar(s)
- docs/* - developer documentation (programming guide???)
- docs/api/* - library javadoc
- demo/* - demo source code and ant files to build demos
|