Version Control on Mac OS X, Part 3by Kevin O'Malley
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
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.
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).
See "Release Management Within Open Source Projects" by Justin R. Erenkrantz for more information on release management on open source projects.
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:
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.
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
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
Step 3: Tag the Release
The next step is to record the new release. To do this, you use the CVS
command to associate a label with all files that make up the release.
% cd MyPing % cvs tag release_1_0-public-release
tag command does not support adding comments (like
commit), it's a good idea to include as much information as possible in the tag
Step 4: Announce the Release
Finally, notify users that the new release is ready and tell them where they can download the software.