From 841b9176d6ba3010584e7d6fdd41677215e09872 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Wed, 28 Feb 2007 18:08:58 +0000 Subject: r11994@catbus: nickm | 2007-02-28 13:08:52 -0500 Re-number misnumbered spec sections. No more having to refer to "the first of two section 6.1s." svn:r9683 --- dir-spec-v1.txt | 10 +++---- dir-spec.txt | 10 +++---- path-spec.txt | 2 +- rend-spec.txt | 2 +- version-spec.txt | 90 +++++++++++++++++++++++++++----------------------------- 5 files changed, 55 insertions(+), 59 deletions(-) diff --git a/dir-spec-v1.txt b/dir-spec-v1.txt index d5381c0..84cea4e 100644 --- a/dir-spec-v1.txt +++ b/dir-spec-v1.txt @@ -62,7 +62,7 @@ $Id$ they would not recognize "keyword ....."; and MUST treat "opt keyword ....." as synonymous with "keyword ......" when keyword is recognized. -8.2. Router descriptor format. +2. Router descriptor format. Every router descriptor MUST start with a "router" Item; MUST end with a "router-signature" Item and an extra NL; and MUST contain exactly one @@ -178,7 +178,7 @@ $Id$ [We didn't start parsing these lines until Tor 0.1.0.6-rc; they should be marked with "opt" until earlier versions of Tor are obsolete.] -2.1. Nonterminals in routerdescriptors +2.1. Nonterminals in routerdescriptors nickname ::= between 1 and 19 alphanumeric characters, case-insensitive. @@ -284,15 +284,15 @@ $Id$ "published" YYYY-MM-DD HH:MM:SS - (see 8.3 above) + (see section 3 above) "router-status" list - (see 8.3 above) + (see section 3 above) "directory-signature" NL signature - (see 8.3 above) + (see section 3 above) 5. Behavior of a directory server diff --git a/dir-spec.txt b/dir-spec.txt index 70c164a..9d7c399 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -280,7 +280,7 @@ $Id$ marked "opt". With some future version, the old 'dnsworker' logic will be removed, rendering this option of historical interest only.] -2.1. Nonterminals in router descriptors +2.2. Nonterminals in router descriptors nickname ::= between 1 and 19 alphanumeric characters, case-insensitive. hexdigest ::= a '$', followed by 20 hexadecimal characters. @@ -779,7 +779,7 @@ $Id$ - Clients SHOULD NOT download directory information from non-'V2Dir' caches. -6.1. Managing naming +6.2. Managing naming In order to provide human-memorable names for individual server identities, some directory servers bind names to IDs. Clients handle @@ -806,7 +806,7 @@ $Id$ SHOULD NOT ever use a router in response to a user request for a router called "Unnamed". -6.2. Software versions +6.3. Software versions An implementation of Tor SHOULD warn when it has fetched (or has attempted to fetch and failed four consecutive times) a network-status @@ -814,7 +814,7 @@ $Id$ not listed on more than half of the live "Versioning" network-status documents. -6.3. Warning about a router's status. +6.4. Warning about a router's status. If a router tries to publish its descriptor to a Naming authority that has its nickname mapped to another key, the router SHOULD @@ -831,7 +831,7 @@ $Id$ ... -6.4. Router protocol versions +6.5. Router protocol versions A client should believe that a router supports a given feature if that feature is supported by the router or protocol versions in more than half diff --git a/path-spec.txt b/path-spec.txt index bc5c090..87a7567 100644 --- a/path-spec.txt +++ b/path-spec.txt @@ -43,7 +43,7 @@ of their choices. ATTACHSTREAM commands). Paths constructed through these means may violate some constraints given below. -1b. Terminology +1.1. Terminology A "path" is an ordered sequence of nodes, not yet built as a circuit. diff --git a/rend-spec.txt b/rend-spec.txt index ceb41b6..732970d 100644 --- a/rend-spec.txt +++ b/rend-spec.txt @@ -452,7 +452,7 @@ $Id$ multiple streams to Bob. Alice SHOULD NOT send RELAY_BEGIN cells for any other address along her circuit to Bob; if she does, Bob MUST reject them. -2.0. Authentication and authorization. +2. Authentication and authorization. Foo. diff --git a/version-spec.txt b/version-spec.txt index 5b9aeee..e17c56b 100644 --- a/version-spec.txt +++ b/version-spec.txt @@ -1,49 +1,45 @@ $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" 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 -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. But starting with -0.1.2.1-alpha-dev, we switched to SVN and started using the "-dev" -suffix instead of the "-cvs" suffix. - + HOW TOR VERSION NUMBERS WORK + +1. 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". + +2. 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" 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 + 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. But starting with + 0.1.2.1-alpha-dev, we switched to SVN and started using the "-dev" + suffix instead of the "-cvs" suffix. -- cgit v1.2.3-54-g00ecf