Home Esplora Aiuto
Accedi
piros
/
tor
3
0
Forka 0
File Problemi 0 Pull Requests 0 Wiki
Albero (Tree): 0cb342e859
Rami (Branch) Tag
tor
/
doc
/
spec
/
version-spec.txt

version-spec.txt 2.1 KB
Cronologia Originale

123456789101112131415161718192021222324252627282930313233343536373839404142434445 
  1. $Id$
    2. 

  2. 

  3.                         HOW TOR VERSION NUMBERS WORK
    4. 

  4. 

  5. 1. The Old Way
    6. 

  6. 

  7.  Before 0.1.0, versions were of the format:
    8. 

  8.      MAJOR.MINOR.MICRO(status(PATCHLEVEL))?(-cvs)?
    9. 

  9.  where MAJOR, MINOR, MICRO, and PATCHLEVEL are numbers, status is one
    10. 

  10.  of "pre" (for an alpha release), "rc" (for a release candidate), or
    11. 

  11.  "." for a release.  As a special case, "a.b.c" was equivalent to
    12. 

  12.  "a.b.c.0".  We compare the elements in order (major, minor, micro,
    13. 

  13.  status, patchlevel, cvs), with "cvs" preceding non-cvs.
    14. 

  14. 

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

  16.  say, "0.0.8".  Our first pre-release would be "0.0.8pre1", followed by
    17. 

  17.  (for example) "0.0.8pre2-cvs", "0.0.8pre2", "0.0.8pre3-cvs",
    18. 

  18.  "0.0.8rc1", "0.0.8rc2-cvs", and "0.0.8rc2".  Finally, we'd release
    19. 

  19.  0.0.8.  The stable CVS branch would then be versioned "0.0.8.1-cvs",
    20. 

  20.  and any eventual bugfix release would be "0.0.8.1".
    21. 

  21. 

  22. 2. The New Way
    23. 

  23. 

  24.  After 0.1.0, versions are of the format:
    25. 

  25.     MAJOR.MINOR.MICRO(.PATCHLEVEL)(-status_tag)
    26. 

  26.  The stuff in parenthesis is optional.  As before, MAJOR, MINOR, MICRO,
    27. 

  27.  and PATCHLEVEL are numbers, with an absent number equivalent to 0.
    28. 

  28.  All versions should be distinguishable purely by those four
    29. 

  29.  numbers. The status tag is purely informational, and lets you know how
    30. 

  30.  stable we think the release is: "alpha" is pretty unstable; "rc" is a
    31. 

  31.  release candidate; and no tag at all means that we have a final
    32. 

  32.  release. If the tag ends with "-cvs" or "-dev", you're looking at a
    33. 

  33.  development snapshot that came after a given release.  If we *do*
    34. 

  34.  encounter two versions that differ only by status tag, we compare them
    35. 

  35.  lexically.
    36. 

  36. 

  37.  Now, we start each development branch with (say) 0.1.1.1-alpha.  The
    38. 

  38.  patchlevel increments consistently as the status tag changes, for
    39. 

  39.  example, as in: 0.1.1.2-alpha, 0.1.1.3-alpha, 0.1.1.4-rc 0.1.1.5-rc,
    40. 

  40.  Eventually, we release 0.1.1.6.  The next patch release is 0.1.1.7.
    41. 

  41. 

  42.  Between these releases, CVS is versioned with a -cvs tag: after
    43. 

  43.  0.1.1.1-alpha comes 0.1.1.1-alpha-cvs, and so on. But starting with
    44. 

  44.  0.1.2.1-alpha-dev, we switched to SVN and started using the "-dev"
    45. 

  45.  suffix instead of the "-cvs" suffix.
    46.