<!-- Content Here -->

Where content meets technology

Jun 04, 2007

A Tale of Two Releases

For the past month or so, there has been a lot of activity on the Apache Lenya list about pulling the trigger on the much awaited 1.4 release. For those of you who have not been following this project, 1.4 has been "just around the corner" for what seems like an eternity. After bringing a few new of committers into the fold, it seemed like the project had the momentum to push 1.4 over the hump.

The project was obviously rusty on doing a major release. The 1.2 series has been around since the middle of 2004 and the project was getting comfortable maintaining and incrementally improving it. The dev mailing list has some interesting discussion about code freezes and what to do when you find a blocker right before cutting a release candidate. It is a thought provoking discussion if you are puzzling over the same issues. In the dialog, Gregor Rothfuss sent out this very interesting link to Jonathan Corbet's article A Tale of Two Release Cycles.

The article compares two projects: The Linux Kernel and the GNU Emacs editor. The Linux Kernel has a system of stable and experimental version numbers. Evens (like 2.6.x) are stable, odds are experimental. But the stable releases are not always so perfect right when they come out. Linus's philosophy is that the longer you wait on a release, the more complex it gets. It is better to just get it out, even if it has a couple known bugs. Users of Linux know that the operating system is not without its bugs. However, these bugs are usually are well documented and they are normally tolerable for even demanding, high availability applications. People (techie sysadmins and power uses) who like Linux and keep their kernels current recognize these issues and plan for them. More casual users of Linux go with highly managed distributions like Red Hat Enterprise Linux or SUSE Enterprise that have their own release cycles that buffer their customers from the new releases.

Emacs, conversely, has yet to do a major release since October 2001. Richard Stallman has set the tone that software should not be released with known bugs (that is an exaggeration but you get the idea). The Corbet's article is critical of Emac's long delays saying "It's not only users who get frustrated by long development cycles; the developers, too, find them tiresome. Projects which adopt shorter, time-based release cycles rarely seem to regret the change."

While I agree with the principle of "release early and often," much of depends on the context. For example, Emacs was probably not hurt by a slow release cycle. The Emacs users I know love the editor because it is familiar to them and they have built all of these macros and shortcuts to make the software their own. New hardware and new computing demands probably make it more important to push a operating system kernel forward aggressively.

To bring the topic to content management, a lot is going to depend on the user community. Some business users are looking for stability first and features second. Other users get excited by new versions of the system and are willing to report bugs and do work-arounds until they are addressed. If you have users like this and can build a partnership where they want to work with you to push the software forward, great! Ideally, the architecture is modular so the core of the application remains reliable and stable while new experimental features (that may be a little rough around the edges) are released. You can look at Emacs this way. The core application stays the same but users are constantly playing with their own new customizations.

Most importantly, projects should adhere to a release schedule to prevent the build-up of unreleased features that will become a regression nightmare when the version is finally released. Preview releases are also a good idea to keep the more daring/tolerant users of the software engaged. This is the best time to get feedback on the new concepts you are exploring. You don't want to know that a feature is useless after you got it "perfect."