Project overview
- Patches. Several high-priority bug fixes to Release 1.0 are needed.
- Minor enhancements. Some commands need new options; some option names need to be shortened (for example, –recursive becomes –r); some algorithms need performance work.
- Major new features. A graphic user interface is required, as are many new commands and internationalization support.
- Several Release 1.0 patch releases will ship before Release 2.0 is complete.
- New features take longer to complete than minor enhancements.
- Some new features depend on the minor enhancements.
The plan uses a baseline-plus-changes approach. Periodically, developers stop writing new code, and spend some time integrating their work, building, and testing. The result is a baseline: a stable, working version of the application. You can integrate product enhancements incrementally and frequently. The more frequent the baselines, the easier the tasks of merging work and testing the results.
After a baseline is produced, active development resumes; any new efforts begin with the set of source versions that went into the baseline build.
You define a baseline by assigning the same version label (for example, R2_BL1 for Release 2.0, Baseline 1) to all the versions that go into, or are produced by, the baseline build.
The project team is divided into three smaller teams, each working on a different development effort: the MAJ team (new features), the MIN team (minor enhancements), and the FIX team (Release 1.0 bug fixes and patches). Some developers may belong to multiple teams. These developers work in multiple views, each configured for the respective team tasks.
The development area for the monet project is shown here.
/vobs/monet | (project top-level directory) | |
|
src/ | (sources) |
|
include/ | (include files) |
|
lib/ | (shared libraries) |
At the beginning of Release 2.0 development, the most recent versions on the main branch are labeled R1.0.