able, with three-number versioning—
Major.Minor.BugFix—where the major
version changes for large features, the
minor version changes for small features, and the last number is a bug-fix
release. The bug-fix number is perhaps
the easiest to understand. After a number of bugs are fixed, you want to release
new software into the field so that users
can benefit from the work your team
has done. Increase the last number and
release a new version. Bug fixes should
never change an API in a library or introduce or significantly change a feature.
The difference between a major and
a minor version change can be tricky
depending on the software you are
writing. Minor versions can be rolled
out so long as there are no backward-incompatible changes to the system.
What this means is that if you have a
change to your software that will break
another piece of software that depends
on your code, or that breaks a user
assumption about how your system
works, that requires a major version
change. Additive changes, such as new
APIs, or new features that do not break
backward compatibility can be rolled
into minor version updates.
The slippery slope is figuring out
how many minor changes add up to a
major change. If your software has 30
features and you add 10 new ones, even
if none of them touches the original 30,
shouldn’t that necessitate a major version change? I think it should, but not
everyone agrees. Of course those who
don’t agree—well, let’s just leave that
alone, shall we?
One thing that software versions
communicate is the rate of change in
your software. If your software goes
from 1.0 to 2.0 in a month, then either
your team is performing miracles,
which I find highly suspect, or they’re
claiming major changes when none
has really occurred. A very high rate of
minor or bug releases can also indicate
problems in a project—in particular,
that it is buggy. Although there is no
perfect rate for releases, they should
definitely slow down a bit as a product
matures. Too-frequent releases often
mean that a piece of software is immature and perhaps lacks staying power.
Another pattern, in some projects,
is never to release a 1.0, but to release
a lot of 0.x’s. A particularly egregious
version of this, pun intended, was the
the difference
between a major
and a minor version
change can be tricky
depending on
the software you
are writing.
Ethereal project, which, after more
than 10 years of development, got to
the point of releasing a 0.99.5. This was
just a way, as far as I could tell, of moving the version number to the right.
The software itself is quite good and
widely used, but its versioning system
was quite odd. Now that the project has
been renamed Wireshark, it seems to
have moved to a more traditional Ma-jor.Minor style of versioning.
Version numbers should also be able
to correlate related pieces of software.
One of the banes of my existence is
the Linux versioning system, although
I believe this has more to do with the
way Linux itself is developed. The fact
that there are now many different
operating-system kernels that I might
have to choose from to use a piece of related software is simply maddening. A
recent example involves having to find
the correct bits so I could use a driver
for a new piece of hardware. The standard release was 2. 6.18-194.3.1.el5, but
the version I needed was, 2. 6.18-164.el.
And just what do those numbers mean?
Of course I could work them out with
some Web searches, but still, the fact
that kernel APIs have changed enough
within those minor releases that a
driver couldn’t work is madness. Even
looking at kernel.org, the source of all
things Linux kernel, isn’t much help. At
the time this column was written these
are the kernels that are listed as stable
for the 2. 6 version of the kernel:
2. 6. 34
2. 6. 33. 5
2. 6. 32. 15
2. 6. 31. 13
2. 6. 27. 47
2010-05-16
2010-05-26
2010-06-01
2010-04-01
2010-05-26
Now, I ask you, how does 2. 6. 34
come out 10 days before 2. 6. 33. 5, and
how can all of these be stable? How do
they even relate to each other?
Of course, it’s not just open-source
projects that have problems with versioning. The biggest software company
of them all seems to have one of the
most ridiculous versioning schemes
of all. Based on the names alone, how
does one figure the difference between
Windows 95, Windows 98, Windows
ME, Windows NT, Windows XP, Windows XP Service Pack 2, and Vista? I
can list them in order only because I
have watched them all come and go,
and, happily, never installed any of
them on my own machines. Perhaps
if you hash the names just right, then
they turn into monotonically increasing version numbers.
One last thing to note is that you
should not tie yourself down with your
versioning scheme; remember that you
may have to be flexible. I once worked
on a product with a 1.0.1b release. The
b release was necessitated by a not-so-amusing mistake, wherein a developer
decided that if a user saved a file without an extension, the developer would
provide one. The extension was a four-letter word that is included in George
Carlin’s list of seven things you can
never say on TV, and which one should
never really have as a file extension either. I think you get the idea. The developer had meant to remove that particular feature before the code was released
but forgot, and so, we had 1.0.1 and
1.0.1b releases. We could have made a
1.0.2 release, but, really, there was just
one change—though I do believe we
should have made the release 1.0.1f.
KV
Related articles
on queue.acm.org
A Conversation with Steve Bourne,
Eric Allman, and Bryan Cantrill
http://queue.acm.org/detail.cfm?id=1454460
Making Sense of Revision-Control Systems
Bryan O’Sullivan
http://queue.acm.org/detail.cfm?id=1595636
George V. neville-neil ( kv@acm.org) is the proprietor of
neville-neil consulting and a member of the acM Queue
editorial board. he works on networking and operating
systems code for fun and profit, teaches courses on
various programming-related subjects, and encourages
your comments, quips, and code snips pertaining to his
Communications column.
copyright held by author.