Subversion 1.5: A Case Study in Open Source Release Mismanagement
Hyrum K. Wright and Dewayne E. Perry
Empirical Software Engineering Laboratory
Department of Electrical and Computer Engineering
The University of Texas at Austin
Austin, Texas 78712
fhwright,perryg@ece.utexas.edu
Abstract
In June 2008, the Subversion development team released
Subversion 1.5.0. This release contained a number of new
features, but arrived only after a long and difficult develop-
ment, test and release cycle. This protracted process con-
fused and frustrated both users and developers. In this pa-
per, we discuss the events which led to this breakdown, how
the release process is being improved, and what lessons
other open source projects can learn from the Subversion
community’s mistakes.
1 Introduction
Open source projects rely upon timely and quality re-
leases to encourage higher user adoption and attract devel-
opers. These releases are the public image of the project,
and influence both mindshare and market share. Users
adopt projects they see as responsive to their needs, while
developers enjoy being part of a vibrant development com-
munity. A timely release process can help achieve these
goals.
Subversion is a popular version control system whose
initial goal was to replace the aging CVS with a more mod-
ern design and feature set. With the release of Subversion
1.4.0, these goals were largely accomplished, and the com-
munity focused on making additional improvements to Sub-
version. These included features requested by both open
source users and corporate deployments, with the primary
one being merge tracking.
As the release manager, one of the authors saw first-hand
the frustration and confusion caused by the protracted re-
lease cycle for Subversion 1.5.0. This release cycle lasted
much longer than anticipated, which negatively impacted
both users and developers. This paper offers a retrospec-
tive view of an actual release experience, how it could have
been better, and what the community is doing to improve
the process for future release cycles.
We recount the history of the Subversion 1.5.0 release
process, which ultimately ended in the delivery of Subver-
sion 1.5.0 in June 2008, more than a year after planned, and
almost two years after Subversion 1.4.0. We discuss the
established process of creating a Subversion release, how
that process helped and hindered the 1.5.0 release, and ulti-
mately what lessons can be learned from this experience for
Subversion and other open source projects. We also discuss
the subsequent steps the Subversion community is taking to
address these issues in upcoming feature releases.
2 Subversion Release Process
In the early days of the project, Subversion developers
established a guiding document known as the “Hacker’s
Guide to Subversion” [2]. Colloquially referred to as
HACKING, this document outlines many aspects of com-
munity processes and procedures, including release pro-
cesses. Although the community allows for circumstantial
variation in these processes, HACKING is fairly specific as
to how the release process should proceed.
Crafting a release of Subversion involves many individu-
als in a coordinated effort following established procedures.
In the following sections, we describe the roles these indi-
viduals fill, the different types of releases, and the version
numbering scheme for Subversion releases. We also de-
scribe the process used to create a new feature release of
Subversion. In Section 3, we compare the ideal described
here with what actually happened when releasing Subver-
sion 1.5.0.
2.1 Community Roles
In a large and complex open source community, such
as Subversion, different members take on different roles