aboutsummaryrefslogtreecommitdiff
path: root/version-spec.txt
diff options
context:
space:
mode:
authorNick Mathewson <nickm@torproject.org>2005-03-19 05:07:19 +0000
committerNick Mathewson <nickm@torproject.org>2005-03-19 05:07:19 +0000
commita2b227c1a235b973f121a2932cdd3990095c522f (patch)
tree4bc899457b23fa5d27a843cd08a03ee4ad69000d /version-spec.txt
parente5a2770e69fb214e467b840c54206c0dec760f8e (diff)
downloadtorspec-a2b227c1a235b973f121a2932cdd3990095c522f.tar.gz
torspec-a2b227c1a235b973f121a2932cdd3990095c522f.zip
Split version info into separate spec doc.
svn:r3783
Diffstat (limited to 'version-spec.txt')
-rw-r--r--version-spec.txt46
1 files changed, 46 insertions, 0 deletions
diff --git a/version-spec.txt b/version-spec.txt
new file mode 100644
index 0000000..85a964a
--- /dev/null
+++ b/version-spec.txt
@@ -0,0 +1,46 @@
+$Id$
+
+HOW TOR VERSION NUMBERS WORK
+============================
+
+The Old Way
+-----------
+
+Before 0.1.0, versions were of the format:
+ MAJOR.MINOR.MICRO(status(PATCHLEVEL))?(-cvs)?
+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 "0.0.8.1-cvs",
+and any eventual bugfix release would be "0.0.8.1".
+
+
+The New Way
+-----------
+
+After 0.1.0, versions are of the format:
+ MAJOR.MINOR.MICRO(.PATCHLEVEL)(-status_tag)
+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", 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 lexically.
+
+Now, we start each development branch with (say) 0.1.1.1-alpha. The
+patchlevel increments consistently as the status tag changes, for
+example, as in: 0.1.1.2-alpha, 0.1.1.3-alpha, 0.1.1.4-rc 0.1.1.5-rc,
+Eventually, we release 0.1.1.6. The next patch release is 0.1.1.7.
+
+Between these releases, CVS is versioned with a -cvs tag: after
+0.1.1.1-alpha comes 0.1.1.1-alpha-cvs, and so on.