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

doc/spec/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
 

doc/spec/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

doc/spec/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.
 

doc/spec/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.
 

doc/spec/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.