3 HOW TOR VERSION NUMBERS WORK
4 ============================
9 Before 0.1.0, versions were of the format:
10 MAJOR.MINOR.MICRO(status(PATCHLEVEL))?(-cvs)?
11 where MAJOR, MINOR, MICRO, and PATCHLEVEL are numbers, status is one
12 of "pre" (for an alpha release), "rc" (for a release candidate), or
13 "." for a release. As a special case, "a.b.c" was equivalent to
14 "a.b.c.0". We compare the elements in order (major, minor, micro,
15 status, patchlevel, cvs), with "cvs" preceding non-cvs.
17 We would start each development branch with a final version in mind:
18 say, "0.0.8". Our first pre-release would be "0.0.8pre1", followed by
19 (for example) "0.0.8pre2-cvs", "0.0.8pre2", "0.0.8pre3-cvs",
20 "0.0.8rc1", "0.0.8rc2-cvs", and "0.0.8rc2". Finally, we'd release
21 0.0.8. The stable CVS branch would then be versioned "0.0.8.1-cvs",
22 and any eventual bugfix release would be "0.0.8.1".
28 After 0.1.0, versions are of the format:
29 MAJOR.MINOR.MICRO(.PATCHLEVEL)(-status_tag)
30 The stuff in parenthesis is optional. As before, MAJOR, MINOR, MICRO,
31 and PATCHLEVEL are numbers, with an absent number equivalent to 0.
32 All versions should be distinguishable purely by those four
33 numbers. The status tag is purely informational, and lets you know how
34 stable we think the release is: "alpha" is pretty unstable; "rc" is a
35 release candidate; and no tag at all means that we have a final
36 release. If the tag ends with "-cvs", you're looking at a development
37 snapshot that came after a given release. If we *do* encounter two
38 versions that differ only by status tag, we compare them lexically.
40 Now, we start each development branch with (say) 0.1.1.1-alpha. The
41 patchlevel increments consistently as the status tag changes, for
42 example, as in: 0.1.1.2-alpha, 0.1.1.3-alpha, 0.1.1.4-rc 0.1.1.5-rc,
43 Eventually, we release 0.1.1.6. The next patch release is 0.1.1.7.
45 Between these releases, CVS is versioned with a -cvs tag: after
46 0.1.1.1-alpha comes 0.1.1.1-alpha-cvs, and so on.