Use of branches

In general, different kinds of work are done on different branches. The Release 1.0 bug fixes, for example, are made on a separate branch to isolate this work from new development. The FIX team can then create patch releases that do not include any of the Release 2.0 enhancements or incompatibilities.

Because the MIN team will produce the first baseline release on its own, the project manager gives the main branch to this team. The MAJ team will develop new features on a subbranch, and will not be ready to integrate for a while; the FIX team will fix Release 1.0 bugs on another subbranch and can integrate its changes at any time.

Each new feature can be developed on its own subbranch, to better manage integration and testing work. For simplicity, work for new features can be done on a single branch.

The project manager has created the first baseline from versions on the main branches of their elements. But this is not a requirement; you can create a release that uses versions on any branch, or combination of branches.

The evolution of a typical element during Release 2.0 development is shown in Development milestones: evolution of a typical element.

The evolution of the element proceeds in the following steps:

1. Start minor and major enhancements, along with R1.0 bug fixing (all branches).
2. Freeze minor enhancements work (main branch).
3. Merge bug fixes from Release 1.0.1 into minor enhancements (main).
4. Create Baseline 1 release (main).
5. Freeze major enhancements work (major).
6. Merge Baseline 1 changes into major enhancements (major).
7. Freeze minor enhancements work (main).
8. Merge additional bugfixes into minor enhancements (main).
9. Freeze major enhancements work (major).
10. Merge major enhancements work with minor enhancements work (main).
11. Create Baseline 2 release (main).
12. Begin Final testing (main).
13. Release 2.0 is done (main).