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

Train pulling out of a freight house at a Chicago and Northwestern Railroad yard. The wooden trestle is part of a long chain belt used to carry blocks of ice from the ice house to the freight house. Chicago, Illinois, December 1942.

You're finishing up a release and also need to start development on the next release. You want to maintain an Active Development Line (5).

Note

How do you stabilize a codeline for an impending release while also allowing new work to continue on an active codeline?

Before a release is ready to ship, there is often much work to do to get the active development line shippable. There are last-minute bugs to fix and last-minute details related to installation to tend to, packaging, and so on. It is best not to do any major new work on the active development codeline while this cleanup is going on because you don't want to introduce any new problems. You should have very restrictive check-in and QA policies during this cleanup period.

One solution is to freeze development on the active development line until the release stabilizes. You can institute a strict policy that only essential changes are made to the codeline. If things go well, this may take only a day or so. But the stabilization work may involve part of the team, and there is new work to do for the next release, so you do not want to stop work at all. If the code freeze lasts longer than this, it is very wasteful of resources and frustrating to developers who are doing new work because they will have to work without the version control system. If people work on the changes without checking them in to the version control stream, you lose all the benefits of having a version control system and put yourself at risk of having chaos when the freeze is lifted.

Another possible solution is to branch the codeline into a release codeline and do all your work on the branch. If you branch too early, you will have to do a lot of merging between the release line and the mainline. Branching gives you isolation but at the expense of added work in doing merges.

Developers want to get work done and avoid merges. Management wants the current code to be stable.

Branch Instead of Freeze

Note

Create a release engineering branch when code is approaching release quality. Finish the release on this branch, and leave the mainline for active development. The branch becomes the release branch.

You mark the release of a product with a branch. Instead of branching immediately after release, branch before the release. This enables you to branch instead of freeze. Instead of freezing the main codeline during release engineering activities, create a separate line for release integration and engineering, and allow other development to continue on the development line.

Create the release engineering line when the code is approaching stability. The closer to “done” code you create the branch, the less merging you will have to do between this line and the mainline. The trade-off is that if you wait longer, you may find yourself in a code-freeze situation.

This anti-freeze (release engineering) line becomes the release maintenance line after a successful release. It still serves the same purpose of “sync and stabilize,” but now it is an ongoing effort that continues even after the release.

In reality, there may be a small “freeze” window—as long as it takes to create a consistent branch. If you can avoid this, all the better, but even if your “freeze” is short, you are still ahead of where you were when you had to freeze until you ship and release. Figure 18-1 illustrates this structure.

Figure 18-1. Release-Prep Code Line

Changes can take place in each of the two codelines at the appropriate pace. Critical fixes and enhancements can be implemented and delivered without immediately impeding future development. Maintenance releases or “patches” can be periodically released without severely impacting development on the next release. The codeline owner of the development line can set a policy for how and when changes are propagated from the maintenance line to the development.