1 Introduction
Over Thanksgiving 2000, I had the opportunity to speak to my mother about the release management I was doing at work. She seemed intrigued by the idea of a release manager, and saw the need for this role in a project she was working on. Unable to find a formal job description, I wrote this document as an explanation.
Since she was going to forward it on to proprietary software project managers, I took care to explain some of the differences in the two styles of development. It is by no means complete, but it should impart a sense of the issues involved.
2 Blessed Binary vs. Automated Build Tree
All development I do is for free software (or open source software, if you will). The word "free" refers not to the cost, but to the fact that all users have the freedom to modify and redistribute it. As such, the development model is a little different.
With proprietary software, release management involves making sure that you have a running executable program that passes certain tests. It's what my colleague Ben Woodard calls the "blessed binary approach". The release manager takes all of the source code and data files from all over the project and hacks them together by hand until there is a working product.
In the free software world, however, we use a different tactic. Since the preferred form of software distribution is an archive of source code, we provide a set of scripts to automatically compile and build the application on a variety of platforms. This traditionally was a complicated affair, given the large number of subtle differences between operating systems.
The trick is that we use a set of tools known as autoconf, automake, and libtool. The details are probably not important here, but the key is that they take away much of the work involved in making source code compile on a variety of unix-like platforms (including the cygwin environment under Microsoft Windows).
3 Release Manager vs. Project Manager
The release manager is traditionally the person in charge of "autoconfiscating" a development tree, as well as adding information necessary for making software installation packages (Deb packages under Debian, RPM packages under Red Hat and its cousins, or InstallShield for Microsoft operating systems). In addition, the release manager manages bug tracking and software testing.
This is rather different from a project manager. The project manager handles the development of new features or tools, and plots the development roadmap for the project. The project manager typically does a lot more personnel management as well, except in the case where a release deadline is coming up (in which case the right of imperium is handed over to the release manager).
Typically in the free software world, there are two current releases of any project: the "stable" or "release" version, and the "unstable" or "development" version. In addition there may be public CVS servers where one can download up-to-the-minute versions of a given project. In many cases the project manager or maintainer handles the development tree, and the release manager works on the stable tree.
4 Bug Resolution and Testing
The release manager also handles software testing. Again, in the free software world, we also test to make sure that the software compiles smoothly and noiselessly on a variety of platforms. Both development models require application tests. In the project I'm currently working on, I included the testing script in the standard source code archive.
Not all bugs are caught by automated tests, however. This is particularly so with run-time errors. When a user finds a bug, it is typically fixed first in the development tree, since that is what the developers are actively working on most of the time. It is then the release manager's job to "back-port" the fix to the most recent stable release, and to notify users of updates.
The release manager must of course perform triage on the list of bugs to determine whether or not it's worth back-porting. Security holes are typically referred to as "release-critical", while cosmetic changes are often deemed to be "wishlist". This is all up to the release manager's discretion.
5 Summary
So, to recap:
The release manager is in charge of