Practical Perforce

Chapter 9. Release Codelines

It’s June, the mainline abounds with completed development, and it’s time to branch a new release. In this chapter we take a look at the care and feeding of release codelines .

We’ll use Ace Engineering’s repository for our examples. In fact, we’ll put ourselves in the role of Ace Engineering’s release manager for the example scenario that runs through the chapter. The filespecs of interest to us are:

//Ace/MAIN/...

The mainline

//Ace/REL1/...

The codeline that supports our 1.X releases

//Ace/REL2/...

The codeline we’re going to create and use for our second major release

The top-level modules that make up our release codelines are:

db/...
built/...
doc/...
gui/...
tests/...
utils/...

(Remember, these names, paths, and filespecs are shorter than you’re likely to need in the real world. We keep them short here so the examples fit on the page.)

Creating a Release Codeline

In preparing to branch the new release codeline, we’ll create a branch view and a label view, label the modules we’re going to branch, and set up a master workspace. Before doing any of these things, however, we have to decide when to branch the codeline, what to call it, who owns it, and what belongs in it.

When should we branch?

As you read in Chapter 7, the mainline leaps (or creeps) forward with changes delivered from development codelines. When our development goals have been reached, we make a release.

Of course, software must be stabilized before it is released. (That is, it has to be ...