Photo by Jack Delano. Library of Congress, Prints & Photographs Division, FSA-OWI Collection, Reproduction Number: LC-USW3-014014-E.

Freight operations on the Chicago and Northwestern Railroad between Chicago and Clinton, Iowa. The rear brakeman signals the engineer to test the brakes by applying and releasing them. This is the signal for “apply.” January 1943.

You want to maintain an Active Development Line (5). You have released versions that need maintenance and enhancements, and you want to keep the released code base stable. This pattern shows you how to isolate released versions from current development.

Note

How do you do maintenance on released versions without interfering with your current development work?

Once you release a version of a product or component, it may need to evolve independently of your primary development. Although it might be ideal from your perspective for your customers simply to update to new releases to get bug fixes, the reality is that in many circumstances you need to make a fix based on the already shipped version of the codeline. You may need to fix an urgent problem, and the new release will not be ready in time. If your application has data migration or a complicated deployment process for it, your customers may not be willing or able to upgrade immediately. You are often faced with the problem of how to conduct development of a future release while at the same time responding in a timely manner to all the many bug reports and enhancement requests that are inevitably going to be logged against the active development.

You need to identify what code was part of the release and what code is in the main development stream. One way to identify what is in a release is by labeling the release in the current codeline, shipping that snapshot, and then continuing to work on the mainline. Figure 17-1 illustrates this approach. Doing things this way does not allow you to fix something in a released product independently of the mainline. Although you need to fix bugs on released products, the current development line may be evolving in a direction that is quite different from the soon to be delivered release, and it may not be easy to deliver a fix quickly.

Figure 17-1. Doing all your work on the mainline

You can create a branch when the product ships to isolate the release line from current work. Then if there are fixes that apply to both the branch and the mainline, you need to merge the changes or duplicate the work. Figure 17-2 shows this situation.

Figure 17-2. Create a branch when you ship

You can put your new work on a branch and ship the mainline. You then can merge back. This means that most developers need to merge their work; hopefully, the released code won't change too much over time. You may have more than one customer, each with variations of the released software; you may need to keep track of multiple releases that are derived from other releases. You can model this by using the staircase structure shown in Figure 17-3. This structure makes it very hard to figure out what code is common among the releases.

Figure 17-3. Staircase of dependent branches

You can try to keep customers on only major releases. Critical bug fixes and enhancements need to be effected immediately, often well before the next major release is ready to ship.

The maintenance effort (bug fixes and enhancements) in the current release may be incompatible with some of the functionality or refactoring already implemented in the next release.

Branch Before Releasing

Note

Split maintenance/release and active development into separate codelines. Keep each released version on a release line. Allow the line to progress on its own for bug fixes. Branch each release from mainline.

Rather than trying to accommodate maintenance of the current release and development of the next release in the same codeline, split maintenance and development into separate codelines. All bug fixes and enhancements to the current release take place in the maintenance line, and effort for the next major release takes place in the development line. Ensure that changes in the maintenance line are propagated to the active development line regularly. Figure 17-4 shows this structure.

Figure 17-4. Release line

Propagate bug fixes from the mainline to the release line where possible. Once the mainline has progressed, you may still be making changes to the released line; code on the release line becomes dead-end code when that release is no longer supported.

When you are ready to ship, label the code on the mainline, and branch. Fix any errors on the released codeline on the branch, and merge any relevant changes back into the mainline before the next release. All work for future releases goes on the mainline.

At release time, branch all code, including third-party code.