Skip to content
Snippets Groups Projects

SupportPolicy

Last edited by Alexander Færøy

Notes and proposed policy for what versions of stuff we support how well for how long

Tor version status

A Tor version number is of the form major.minor.micro.patchlevel[-status][-dev]. The "major.minor.micro" part denotes a "release series", the "patchlevel" says which release in that series it is, and the "-status" is a human-readable description of the release's stability. A release's "-status" is one of "-alpha", "-beta", "-rc", or "". In the past, we have moved from unstable status monotonically toward more stable status, though that is not guaranteed. We might at some point in the future release "-rc" releases between stable releases so that we can try out patches before declaring them officially stable.

Version numbers with a "-dev" suffix are not real releases. They are made from the git repository (formerly svn) between official releases.

The lifecycle of a release does not correspond perfectly to its status tag. Tor series tend to go through the following stages.

  • 0-alpha-dev: For a while after a release series forks off from the one before it, it has not even been released yet. This tends to be where huge feature merges happen. Here be dragons.
  • Alpha: Alpha releases have lots of new features in them. We make an effort not to release alphas with known showstopper issues, but it is expected that users running alphas will still encounter some bugs and maybe help us hunt them down.
  • Feature-freeze: At some point during the release series, we stop accepting new features. This feature freeze is more of a slow frost than an instantaneous cold snap, as features with an unusually high utility-to-complexity ratio may still get accepted right after the feature freeze begins. As time passes and the freeze deepens, our requirements for new features become progressively more strict.
  • Release candidate: We call a version of Tor a release candidate when we have fixed all of the known bugs that should stop reasonable people from running it, and all of the features have been in enough alphas that we're confident they work well.
  • Stabilizing: We call a version of Tor stable when it has had a couple of -rc releases with no big new bugs found, and all of the known bugs that should stop reasonable people from running it are resolved. In practice, the first few stable releases are "stabilizing" releases, where the additional testing and attention they get shakes out new bugs.
  • Solid: With the first declared stable release in a series, we usually get new bug reports as more people try it out. With the next few releases, these get sorted out, to the point where new bugs are found infrequently, and the ones that are found are not too severe.
  • Legacy: Once there are at least two solid release series, the older one tends to get only the really severe bugfixes propagated back to it.
  • Unsupported: After a while, we forget to backport stuff to a release series. Eventually, we tell everybody, "yeah, don't expect a new release in this series," but it keeps working for a little while, thanks to no effort of ours.
  • Dead: A dead series will not work on the current Tor network. The software is totally unsupported.

The Tor life-cycle in practice

In practice, when one series is around "feature freeze" or "release candidate" status, we fork the next one. The first series tends to become "solid" well before the next one is in "feature freeze". We tend to let a release become unsupported once a newer release is solid, though we rarely do this as a conscious decision.

Here are the timelines for the last few release series, as judged by nickm:

  • 0.1.2.x:
    • 0-alpha-dev on 10 April 2006.
    • First alpha on 27 August 2006.
    • Feature freeze occurred between 0.1.2.7-alpha (6 Feb 2007) and 0.1.2.8-beta (26 Feb 2007)
    • Release candidate (0.1.2.9-rc) on 2 March 2007.
    • Declared stable release as of 0.1.2.13 on 24 April 2007.
    • Solid around 0.1.2.17 (30 Aug 2007) or 0.1.2.18 (28 Oct 2007)
    • Last release 0.1.2.19 (17 Jan 2008)
    • Declared unsupported with release of 0.2.0.34 on 8 Feb 2009.
    • Dead as of early 2010.
  • 0.2.0.x:
    • 0-alpha-dev on 4 March 2007
    • First alpha on 1 June 2007
    • Feature freeze between 0.2.0.19-alpha (9 Feb 2008) and 0.2.0.20-rc (24 Feb 2008)
    • Release candidate (0.2.0.20-rc) on 24 Feb 2008
    • Declared stable release as of 0.2.0.30 on 15 July 2008.
    • Solid around 0.2.0.34 (8 Feb 2009)
    • Last release was 0.2.0.35 on 24 Jun 2009.
    • Currently "old" or "unsupported".
  • 0.2.1.x:
    • 0-alpha-dev on 26 Feb 2008.
    • First alpha on 13 Jun 2008
    • Slow feature freeze between 0.2.1.13-alpha (9 Mar 2009) and 0.2.1.17-rc (7 Jul 2009)
    • Release candidate (0.2.1.14-rc) on 12 Apr 2009
    • Declared stable release as of 0.2.1.18 on 24 Jul 2009.
    • Solid around 0.2.1.20 on 15 Oct 2009.
    • Currently "Solid".
  • 0.2.2.x:
    • 0-alpha-dev on 29 Apr 2009
    • First alpha on 26 Aug 2009
    • Slow feature freeze during Sep 2010
    • No release candidate yet.
  • 0.2.3.x:
    • 0-alpha-dev on 24 Sep 2010
    • No alpha yet.

So looking at the last few release series, we see these trends:

  • We've spent about 4 months in 0-alpha-dev (between fork and first alpha)
  • Between the first alpha and the feature freeze, we've spent between 5 and 13 months. Each release has spent longer here than the one before. That's not good!
  • Going from a feature freeze to a stable release takes about 4 months.
  • Going from stable to solid takes about 4 months, with high variance.
  • We aren't good at keeping two solid releases at once. As soon as one release is solid, we start forgetting backports to the one before it.

Proposed practices for Tor releases

Here is a proposed policy :

We should make the stable status of each release series explicit.

We should have at least one "Solid" release series at all times. Solidity can be retroactively declared when a couple of months go by with no major bugfix releases. When we declare a release "Solid", the previous "Solid" release becomes "Legacy".

We should declare a planned support interval for each Tor release series, starting with the point at which we declared it stable. History suggests that this has been around 2-2.5 years with no real promises, so something around there should be relatively doable.

We should have real criteria for backporting bugfixes to older release series. I suggest:

  • All bugs in "Stabilizing" get fixed, unless the fix is extremely complex and the impact of the bug is relatively low. Tiny high-impact, low-risk, small-implementation features will also sometimes go into "Stabilizing".
  • Bugs in "Solid" should get fixed if they rise above the merely annoying to create an actual problem for users and operators. No features should be added to Solid.
  • Bugs in "Legacy" should get fixed only if they affect security (e.g., buffer overflows), or they make Tor unusable (e.g., frequent crashes, garbled relay traffic). (Note that anonymity improvements are generally features, not security fixes.)

These criteria need clarification and firming up, perhaps.

Operating system support

Operating systems fall into 3 categories:

  • Supported: If Tor breaks on one of these operating systems, it's a bug we will try to fix. These break down into:
    • Packaged: we build binary packages and bundles for these operating systems.
    • Source-only: if you want Tor on this operating system, you need to install it from source, or use somebody else's bundle.
  • Contrib: We will take patches to keep Tor working on these operating systems, though we don't write them ourselves. If somebody tells us that there is a bug on one of these operating systems, we might try to track it down and fix it, or we might not.
  • Out-of-scope: We will not even take patches to get Tor working on these operating systems.

We should decide which operating systems to support based on:

  • Popularity among our target user communities
  • Popularity among our target developer communities
  • How hard they are to support

Right now, our Supported operating systems are:

  • Windows 2000 and later (Packaged)
  • Mac OSX (Packaged)
  • GNU/Linux
    • Debian (Packaged)
    • Fedora (Packaged)
  • The BSD operating systems
  • Some smartphone OSs?

Our Contrib operating systems include:

  • OpenSolaris
  • Commercial Unixes
  • Windows 98 [I am not sure about this one -NM ]
  • Windows mobile
  • Some smartphone OSs

Our out-of-scope operating systems include:

  • Windows 95 and earlier
  • Mac OSX 10.1 and earlier
  • VMS
  • Anything without an implementation of the berkeley sockets API
  • Anything besides Windows that doesn't make a reasonable attempt at a unix-like API

Other than Windows, I haven't discussed OS versions above. Here is a proposed policy:

  • We should generally support at least whichever versions are supported by the OS vendor when the release series becomes stable.
    • We might also support OS versions that the vendor does not if they have have a very large install base interested in running Tor. This is typically true only for Windows and OSX.
    • We might decline to support very old yet still-supported OS versions if they have a very small install base interested in running Tor.
  • We should not drop support for an OS version during a release series, if we can avoid it. (That is, if Tor 0.2.2.x supports Windows 2000, no subsequent release in the 0.2.2.x series should break on Windows 2000).
  • We should make this policy clear.

Proposed application:

  • 0.2.2.x should be the last series to support any version of Windows before XP/Server 2003.

Required libraries for Tor

In addition to regular OS facilities (libc, libm), Tor requires libz, libevent, and openssl. Proposed policy: Which versions of these libraries a release series may require is determined by what is available on the operating systems we support at the time of calling a release series 'stable'. We should compile a list.

We recommend the newest version of zlib. For security reasons, we require zlib 1.2.3 or later. Older versions of zlib that have had the security fixes backported to them are acceptable. We do not support versions of zlib before 1.1. We will drop support for zlib 1.1 (WHEN?).

We recommend the latest version of Libevent in the 2.0 series, or in the 1.4 series. Failing that, use 1.4.12-stable or later. In extremis, version 1.3e will work. Alphas are not supported, nor are versions before 1.3e, though they might work anyway.

We recommend using a vendor-updated openssl from a responsible OS that keeps packages up-to-date. Failing that, the latest 0.9.8 or 1.0.0 is best. Versions before 0.9.7 are not supported.

Problem: The above paragraphs don't distinguish well between degrees of recommendedness.

Current library status

As of November 2010:

(Version numbers are as declared, and in some cases are heavily patched.)

  • Linux
    • The oldest vendor-supported Debian is Lenny with Libevent 1.3e, openssl 0.9.8o, and zlib "1.2.3.4"
    • The oldest vendor-supported Fedora will soon be Fedora 13, which ships openssl 1.0.0a, libevent 1.4.13, and zlib 1.2.3
    • Ubuntu...
    • RHEL... (This is probably the most long-supported Linux we should consider keeping compatible with)
    • Centos 4 is the oldest supported CentOS. It has zlib "1.2.1.2", openssl 0.9.7a, and I am not sure it even has Libevent.
  • BSD
    • FreeBSD...
    • NetBSD...
    • OpenBSD 4.7 is '''not''' the oldest supported version; it has openssl 0.9.8k and libevent 1.3e
  • Commercial, popular
    • Windows does not ship any of the libraries here; we can ship any version we want.
    • The oldest officially supported version of OSX is 10.5; it has openssl 0.9.7l and zlib 1.2.3

Comments

    Please register or sign in to add a comment.