Streamed Lines: Branching Patterns for Parallel Software Development

Copyright © 1998 by Brad Appleton, Stephen Berczuk, Ralph Cabrera, and Robert Orenstein.
Permission is granted to copy for the PLoP '98 conference.

Table of Contents
[printing/downloading instructions]
Send us your comments!

Basic Branch/Line Elements

E1. Activity Branch

An activity-branch is a branch used to represent a logically discrete unit of effort. The effort might be for effecting a fix or feature, or for building and releasing. If the emphasis is on the functional changes themselves rather than on the effort involved, we would call it a Functional Branch (see below). Related patterns are Branch per Task, Merge Early and Often, MYOC (Merge Your Own Code), Docking Line, and Change Propagation Queues.

E2. Functional Branch

A functional branch is a branch used to represent logically discrete unit of functionality. If it is for a feature or an enhancement, we call it a Feature Branch (E2.1); if it is for a bug-fix, we call it a Fix Branch or a Bugfix Branch (E2.2). Since functional units often map to work-units, a functional branch is often an activity branch too, but not always. A build, or a system integration might be a logical unit of work, but typically not of functionality.

E3. Component Branch

A component branch is a branch or codeline that is primarily intended for work on a specific component of the system. It might be a lone module, component, subsystem, or an entire product within a multi-product project. The patterns Component Line and Staged Integration Lines make use of component branches.

E4. Project Branch

A project branch is a branch or codeline that represents a separate line of development for a particular (sub)project which comprises multiple tasks or activities. It is essentially an activity-branch for a task consisting of multiple discrete activities (or subtasks). Related patterns are Codeline per Release, and Subproject Line.

E5. Development Line

A development line is a codeline upon which development (changes) takes place and which may or may not include maintenance efforts. In the broad sense, it includes maintenance; in the narrow sense, it is only for "new" development. Related patterns are Mainline, Parallel Maintenance/Development, and Remote Line.

E6. Maintenance Line

A maintenance line is a codeline intended primarily for maintenance efforts (bug-fixes and minor enhancements), and possibly for release-engineering efforts as well. Related patterns are Parallel Maintenance/Development, and Deferred Branching.

E7. Integration Line

An integration line is a codeline that is primarily for the purpose of integration (merges) from other codelines and branches. If no other type of work takes place on the integration line, we call it a Receiving Line (E7.1), because all it does is receive changes from other codelines. If, in addition to receiving changes from other codelines, it also propagates those integrated changes to other codelines, then we call it a Shipping/Receiving Line (E7.2). Related patterns are Mainline, Docking Line, Staged Integration Lines, Merge Early and Often, MYOC (Merge Your Own Code), and Change Propagation Queues.

E8. Release Line

A release line is a codeline that represents a logical grouping of delivered functionality (a patch or a release). If it is known to be for a patch (as opposed to a release) we may call it a Patch Line (E8.1). If the codeline corresponds to all releases and patches for the same major release (e.g. all releases with the same major release number, as in "1.x.y") then we may call it a Major Release Line (E8.2), but we will typically just use the blanket term "release-line" to refer to both types. Often, a release-line maps directly to a project-branch, but not always (this is similar to the relationship between functional-branches and activity-branches). If the codeline is strictly for release-engineering activities, as opposed to the development of functionality in the release, then we call this a Release-Engineering Line or a Releasing Line (E8.3). Related patterns are Parallel Maintenance/Development, Parallel Releasing/Development, Overlapping Releases, Codeline per Release, and Early Branching.

[back to the table of contents]

Send us your comments!