Support Policy

Disclaimer: Any changes, features or fixes are at the discretion of the Network Team. We try to follow very tightly the following policy but keep in mind that special cases can arise.

Adopted On: May 9th, 2022

Types of Releases

A Tor (tor.git) release can be in one of 4 states:

• alpha: Development release
• release candidate (rc): Candidate for stable release. No more development on it
• stable: The most recent series that is recommended for general use.
• oldstable: Being deprecated in favor of the new stable. Still suitable for general use until end of life.

Once a release becomes stable, any previous stable release becomes oldstable. The release will remain oldstable for 3 months or until Tor Browser transitions out of it. This grace period is to give time for packagers to roll out the new stable. We also provide this period for the network relay operators to migrate to the new stable.

After that, the release will be considered End of Life (EOL) as in unsupported meaning that at any point after that state is set for the release series, the directory authorities might reject them from the consensus.

Arti vs Tor

At the moment, we are actively working on arti as a tor.git replacement.

In late 2022 or start of 2023, arti will replace tor.git as the defacto client to be used which makes us currently restricting client features going in tor.git to only the funded project.

See our deprecating C tor patches policy page for more details on what can be safely contributed to tor.git.

Levels of Support

Note that, in all supported releases, we update data that is required or recommended for connecting to the Tor network, including authority lists, fallback directory lists, and geoip configuration.

In alpha release series:

• You. Only. Live. Once.

In stable and rc release series:

• NO new features except for security reasons
• All type of fixes are allowed.

In oldstable release series:

Note that old stable are there to allow a transition period to the new stable and generally not to be used for general use.

• Security, Stability and Regression fixes

In End-of-Life (EOL) release series:

• No changes are made.
• No new versions are released.
• You are on your own.

Implications

In general, users and packagers should distribute the stable release whenever possible.

For testing purposes, people should make sure that alpha and rc releases meet their needs, so that bugs can be fixed before those releases are officially stable. Because many kinds of changes are allowed, those releases are where most bugs will be encountered.

Unstable Features

Above we describe circumstances when a release is "supported". Even in supported releases, however, some unstable features may not receive fixes, either because they are less mature than the rest of Tor, because there are relatively few users who need them, or for some other reason.

Examples of unstable features are:

• Enabling Rust support.
• Enabling NSS support.
• Embedding Tor in another binary.
• Running on unsupported platforms (Tier 3 or lower).

Depending on complexity and resources, we may apply fixes to these unstable features in the stable series only, or even restrict such fixes to alpha and rc series.