Release-oriented projects

A project team can organize its work for product releases. First, the team might work on Release 1 of the product. To work on Release 2, the team branches off Release 1 and begins new development work in the Release 2 stream, and, when Release 3 work begins, it might branch off the Release 2 stream.

After Release 1 ships to end users, patches for the release might be developed in its own project, which branches off Release 1. The patch project delivers its work to Release 2, so that the bug fixes can be incorporated into the new release.

This type of project organization results in a cascade of branches that can cause some difficulty. To avoid the difficulty, a slightly different project organization is generally recommended for release-oriented projects (see the following figure).

In the release-oriented organization shown in the following figure, all projects start from a foundation baseline in the Mainline project. The Webotrans_1.0 project delivers its release to the Mainline project. A patch release project Rel_1_Patch can be started from a stable baseline in the project Webotrans_1.0 and can deliver its work to the Mainline project integration stream. Instead of cascading from the previous release, a follow-on project Webotrans_2.0 is then started from the baseline in the integration stream of the Mainline project.

A release-oriented project must have modifiable access to all of the components that are contained in the final product. Developers working on one component of the project need to consistently and frequently coordinate their work with developers working on other components. This type of project organization in UCM works well when there is tight coupling between components.