Version Control on Mac OS X, Part 3

Introduction

Welcome back. In the first article of this series, you were introduced to version control and learned some of its concepts. The second article gave you a chance to apply this knowledge by using CVS from the command line, as well as under Project Builder, on a simple Cocoa program -- MyPing. In this final article of this series, we will look at creating software releases using the CVS tag and branch commands, as well as some Mac OS X GUIs for interacting with a CVS repository.

Adding New Features to MyPing

The first version of MyPing contained minimal functionality. It enabled you to ping a host, control the number of pings, the delay between pings, and view ping's output. These features are useful, but we can do better.

Let's add two new features that enable you to log the output of ping to a file and clear the output of the text view area between pings. I've added these features to MyPing, which you can download and integrate into your latest version. The new additions are notated in the code with comments. You will also need to update your Nib file to get the interface changes. Once integrated, make sure you commit your changes to CVS.

Release Basics

Before using the CVS commands to create a new release, let's look briefly at the basics of release management. Against this backdrop, you will have a better sense for the software release process and get a feel for how it works. If you already understand release management, feel free to skip this section.

As you recall from the first article, version control is a process, supported by software, that helps you manage aspects of the software development process. These include recording changes to your project's source files, controlling access to shared files, and managing releases. Even though the software release process varies from project to project and industry to industry, we can abstract some general properties that enable us to understand the process better.

There are typically three players in the release process: developers, maintainers, and release managers (though more can exist, such as testers). A developer is responsible for writing code, fixing bugs, and adding features to components of the software system. Maintainers are accountable for a particular part (or parts) of the software package. They take contributions from developers, verify additions, and integrate them into the module's code base. Additionally, they can also develop code for a module. The release manager performs the necessary steps to put together and release the software package. This typically involves tasks such as testing, communicating with maintainers, enforcing a code freeze, reviewing code/feature, etc. The release manager can be one person, or a group.

A code freeze is a policy, usually enforced by the release manager, that stops some, or all, types of development on the software system. Freezing can include feature freeze, where no new functionality is added to the software (though small additions like minor bug fixes can be applied) and hard freeze, where nothing new is added to the system.

On many projects, the release policy functions as follows. Developers submit code (bug fixes, patches, features, etc.) to the maintainer of a module. The maintainer accepts or rejects submissions and integrates accepted code into the working code base for the module. Once the principal project members decide to release a new version (the policy varies from project to project), the release manager enforces a code freeze, gets updates from module maintainers, accepts/rejects submissions, performs or coordinates testing, reviews code, and makes sure that the new release is stable. Once the release is ready to go, the release manager announces the new release and makes it available to the public.

Remember, this is the general case; each project can, and often will, have a different release model (for example, the Linux kernel or the Apache server).

For the MyPing project, there is a single developer, you, who will take on all of the roles. Nonetheless, it is useful to understand the usual model so you can see the different roles of the release cycle, even though you are performing all tasks.

Creating a Release of MyPing

CVS contains two commands that help you create software releases: tag and branch. A tag is a label you give to a set of revisions, or files, enabling you to snapshot a fixed point in the project. As you continue editing tagged files, and committing them to CVS, the tag you created remains fixed with the state of the files when they were tagged. At any point, you can return to the past simply by checking out the files by their tag name. We will use the tag command to create a release of MyPing.

The branch command helps you create and manage different versions of your project -- such as release versions, debugged versions, and optimized versions -- without disturbing the main trunk. The trunk is the current state of development; a branch is a specialized version, or diversion. Each branch has a root (the initial state of the branch) and a tip (the current state of the branch). If you create a branch, modify files, and commit the changes, the root and the tip will contain different versions of your files. Further, all commits to a branch do not affect the trunk, only the branch. We will use the branch command to create a specialized version, in our case a bug fix version, of MyPing.

The following diagram shows an example of three branches rooted on the trunk, as well as branches rooted on branches.

Performing a Release with CVS tag

The following steps outline how to create a new release of MyPing.

Step 1: Institute a Code Freeze

Institute a code freeze for the MyPing project, where nothing new is added to the system. At this point, you should commit all code to CVS.

Step 2: Test the Release

Once the code freeze is in place, you can begin creating a new release. First, make sure everything works correctly by performing your predefined tests. For many projects, this means running a script that executes regression testing to verify that the release is stable. If any code is changed, make sure you commit your changes to CVS.

Note: This version of MyPing contains an intentional bug. I did this to demonstrate how to use the CVS branch command to perform bug fixes in a past release. I discuss this technique in the section "Updating a Released Version with CVS Branch."

Step 3: Tag the Release

The next step is to record the new release. To do this, you use the CVS tag command to associate a label with all files that make up the release.

% cd MyPing

% cvs tag release_1_0-public-release

Since the tag command does not support adding comments (like import and commit), it's a good idea to include as much information as possible in the tag name.

Step 4: Announce the Release

Finally, notify users that the new release is ready and tell them where they can download the software.

[1] [2] [3] Next