|
|
= Notes and proposed policy for what versions of stuff we support how well for how long =
|
|
|
# Notes and proposed policy for what versions of stuff we support how well for how long
|
|
|
|
|
|
== Tor version status ==
|
|
|
## 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.
|
|
|
|
... | ... | @@ -8,23 +8,23 @@ Version numbers with a "-dev" suffix are not real releases. They are made from |
|
|
|
|
|
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.
|
|
|
* **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 ===
|
|
|
### 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.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)
|
... | ... | @@ -34,7 +34,7 @@ Here are the timelines for the last few release series, as judged by nickm: |
|
|
* 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.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)
|
... | ... | @@ -43,7 +43,7 @@ Here are the timelines for the last few release series, as judged by nickm: |
|
|
* 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.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)
|
... | ... | @@ -51,25 +51,25 @@ Here are the timelines for the last few release series, as judged by nickm: |
|
|
* 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.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.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!
|
|
|
* 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 ===
|
|
|
### Proposed practices for Tor releases
|
|
|
|
|
|
Here is a '''proposed policy''' :
|
|
|
Here is a **proposed policy** :
|
|
|
|
|
|
We should make the stable status of each release series explicit.
|
|
|
|
... | ... | @@ -85,14 +85,14 @@ We should have real criteria for backporting bugfixes to older release series. I |
|
|
|
|
|
These criteria need clarification and firming up, perhaps.
|
|
|
|
|
|
== Operating system support ==
|
|
|
## 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:
|
|
|
* **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.
|
|
|
* **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
|
... | ... | @@ -109,9 +109,9 @@ Right now, our Supported operating systems are: |
|
|
* Some smartphone OSs?
|
|
|
|
|
|
Our Contrib operating systems include:
|
|
|
* !OpenSolaris
|
|
|
* OpenSolaris
|
|
|
* Commercial Unixes
|
|
|
* Windows 98 [''I am not sure about this one -NM'' ]
|
|
|
* Windows 98 [_I am not sure about this one -NM_ ]
|
|
|
* Windows mobile
|
|
|
* Some smartphone OSs
|
|
|
|
... | ... | @@ -122,8 +122,8 @@ Our out-of-scope operating systems include: |
|
|
* 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.
|
|
|
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).
|
... | ... | @@ -132,9 +132,9 @@ Other than Windows, I haven't discussed OS versions above. Here is a '''propose |
|
|
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 ==
|
|
|
## 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.
|
|
|
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?).
|
|
|
|
... | ... | @@ -144,7 +144,7 @@ We recommend using a vendor-updated openssl from a responsible OS that keeps pac |
|
|
|
|
|
Problem: The above paragraphs don't distinguish well between degrees of recommendedness.
|
|
|
|
|
|
=== Current library status ===
|
|
|
### Current library status
|
|
|
|
|
|
As of November 2010:
|
|
|
|
... | ... | |