You are on page 1of 1

$Id: version-spec.

txt 9683 2007-02-28 18:08:58Z nickm $


1. The Old Way

Before 0.1.0, versions were of the format:

where MAJOR, MINOR, MICRO, and PATCHLEVEL are numbers, status is one
of "pre" (for an alpha release), "rc" (for a release candidate), or
"." for a release. As a special case, "a.b.c" was equivalent to
"a.b.c.0". We compare the elements in order (major, minor, micro,
status, patchlevel, cvs), with "cvs" preceding non-cvs.

We would start each development branch with a final version in mind:

say, "0.0.8". Our first pre-release would be "0.0.8pre1", followed by
(for example) "0.0.8pre2-cvs", "0.0.8pre2", "0.0.8pre3-cvs",
"0.0.8rc1", "0.0.8rc2-cvs", and "0.0.8rc2". Finally, we'd release
0.0.8. The stable CVS branch would then be versioned "",
and any eventual bugfix release would be "".

2. The New Way

After 0.1.0, versions are of the format:

The stuff in parenthesis is optional. As before, MAJOR, MINOR, MICRO,
and PATCHLEVEL are numbers, with an absent number equivalent to 0.
All versions should be distinguishable purely by those four
numbers. The status tag is purely informational, and lets you know how
stable we think the release is: "alpha" is pretty unstable; "rc" is a
release candidate; and no tag at all means that we have a final
release. If the tag ends with "-cvs" or "-dev", you're looking at a
development snapshot that came after a given release. If we *do*
encounter two versions that differ only by status tag, we compare them

Now, we start each development branch with (say) The

patchlevel increments consistently as the status tag changes, for
example, as in:,,,
Eventually, we release The next patch release is

Between these releases, CVS is versioned with a -cvs tag: after comes, and so on. But starting with, we switched to SVN and started using the "-dev"
suffix instead of the "-cvs" suffix.