nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-23 20:03:31 +01:00
Code Issues Packages Projects Releases Wiki Activity

Split version info into separate spec doc.

Browse Source 
svn:r3783
This commit is contained in:
Nick Mathewson 2005-03-19 05:07:19 +00:00
parent 5c59ec8e1b
commit 11aa682812
6 changed files with 55 additions and 36 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
contrib/osx/package.sh
View File

@ -129,7 +129,7 @@ groff doc/tor.1 -T ps -m man | ps2pdf - $DOC/tor-reference.pdf
groff doc/tor-resolve.1 -T ps -m man | ps2pdf - $DOC/tor-resolve.pdf
mkdir $DOC/Advanced
cp doc/tor-spec.txt doc/rend-spec.txt doc/control-spec.txt doc/socks-extensions.txt $DOC/Advanced
cp doc/tor-spec.txt doc/rend-spec.txt doc/control-spec.txt doc/socks-extensions.txt doc/version-spec.txt $DOC/Advanced
cp doc/CLIENTS $DOC/Advanced/CLIENTS.txt
cp doc/HACKING $DOC/Advanced/HACKING.txt
cp ChangeLog $DOC/Advanced/ChangeLog.txt

2
contrib/package_nsis.sh
View File

@ -28,7 +28,7 @@ clean_newlines() {
}
for fn in CLIENTS tor-spec.txt HACKING rend-spec.txt control-spec.txt \
tor-doc.html tor-doc.css; do
tor-doc.html tor-doc.css version-spec.txt; do
clean_newlines doc/$fn win_tmp/doc/$fn
done

2
doc/Makefile.am
View File

@ -1,4 +1,4 @@
EXTRA_DIST = tor-spec.txt CLIENTS FAQ HACKING rend-spec.txt control-spec.txt tor-doc.html tor-doc.css tor-resolve.1
EXTRA_DIST = tor-spec.txt CLIENTS FAQ HACKING rend-spec.txt control-spec.txt tor-doc.html tor-doc.css tor-resolve.1 version-spec.txt
man_MANS = tor.1 tor-resolve.1

7
doc/TODO
View File

@ -116,8 +116,11 @@ R o HTTPS proxy for OR CONNECT stuff. (For outgoing SSL connections to
o Feed end reason back into SOCK5 as reasonable.
R o cache .foo.exit names better, or differently, or not.
o make !advertised_server_mode() ORs fetch dirs less often.
N - Clean up NT service code even more. Document it. Enable it by default.
Make sure it works.
N . NT Service code
o Clean up NT service code even more.
o Enable it by default.
o Make sure it works.
. Document it.
Documentation
o Document new version system.

46
doc/version-spec.txt Normal file
View File

@ -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.

32
src/or/or.h
View File

@ -1790,37 +1790,7 @@ void clear_trusted_dir_servers(void);
/** Structure to hold parsed Tor versions. This is a little messier
* than we would like it to be, because we changed version schemes with 0.1.0.
*
* 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".
*
* After 0.1.0, versions are of the format:
* MAJOR.MINOR.MICRO(.PATCHLEVEL([-.]status_tag)?)?
* 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. 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.
* See version-spec.txt for the whole business.
*/
typedef struct tor_version_t {
int major;