|
|
# Support policy
|
|
|
# Support Policy
|
|
|
|
|
|
(Adopted 18 Feb 2021)
|
|
|
**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.
|
|
|
|
|
|
## Kinds of releases
|
|
|
**Adopted On**: ...
|
|
|
|
|
|
Every Tor release series can be in one of 6 states:
|
|
|
* **alpha**: a release series under destabilizing feature development.
|
|
|
* **release candidate (rc)**: approaching stability.
|
|
|
* **stable**: the most recent series that is recommended for general use.
|
|
|
* **oldstable**: still suitable for general use, but a more recent stable release exists.
|
|
|
* **long-term support (LTS) only**: intended for use by distributors that require a series that receives only minimal patches over time.
|
|
|
## Types of Releases
|
|
|
|
|
|
Once a release becomes "stable", any previous "stable" release becomes "oldstable". The release will remain "oldstable" for 3 months, or until 9 months after it was originally stable: whichever comes last.
|
|
|
A Tor (tor.git) release can be in one of 4 states:
|
|
|
|
|
|
After a release series is no longer "oldstable", it typically becomes "unsupported" -- some releases, however, become "LTS only". We announce in advance which releases are planned for LTS. Once a release is LTS, we commit to _trying_ to keep it as LTS for some interval of time: typically a few years.
|
|
|
* **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.
|
|
|
|
|
|
## Levels of support
|
|
|
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. The 3 months is to give time for packagers to
|
|
|
package and roll out the new stable. We also provide this timeline for the
|
|
|
network relay operators to migrate to the new stable.
|
|
|
|
|
|
In *unsupported* release series:
|
|
|
* No changes are made.
|
|
|
* No new versions are released.
|
|
|
* Nothing is promised.
|
|
|
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](https://gitlab.torproject.org/tpo/core/arti/) as a
|
|
|
[tor.git](https://gitlab.torproject.org/tpo/core/tor/) replacement.
|
|
|
|
|
|
In late 2022, `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.
|
|
|
|
|
|
We **strongly** encourage contributors to develop client side features in
|
|
|
`arti` from now on as there are little changes that we'll accept them in
|
|
|
`tor.git`.
|
|
|
|
|
|
All relays side features are still planned for `tor.git` at the moment.
|
|
|
|
|
|
## Levels of Support
|
|
|
|
|
|
In *all supported release series*:
|
|
|
* We update _data_ that is required or recommended for connecting to the Tor network, including authority lists, fallback directory lists, and geoip configuration.
|
|
|
Note that we update **data** that is required or recommended for connecting to
|
|
|
the Tor network, including authority lists, fallback directory lists, and
|
|
|
geoip configuration in all supported releases.
|
|
|
|
|
|
Additionally, in *LTS-only* releases:
|
|
|
* We fix security bugs that cause vulnerabilities.
|
|
|
* We apply _simple_ patches if they are needed to keep the release functional on the network. (That is, if the alternative to applying the patch is to make one or more use-cases unsupported.)
|
|
|
* We apply _simple_ patches if they are needed to keep the release maintainable. (That is, if our ability to maintain the release would be blocked by not merging the patch.) *[Added 25 Feb 2021]*
|
|
|
* We don't make other changes.
|
|
|
In **alpha** release series:
|
|
|
|
|
|
Additionally, in *oldstable* releases:
|
|
|
- All patches allowed in *LTS-only* releases are permitted.
|
|
|
- Stability fixes are also allowed.
|
|
|
- Relays, clients, and onion services are supported on the network: fixes to keep them working on the network are allowed.
|
|
|
- Dirauths _may_ be supported on the network.
|
|
|
- Other fixes may or may not be backported.
|
|
|
* You. Only. Live. Once.
|
|
|
|
|
|
Additionally, in *stable* and *rc* releases:
|
|
|
- All patches allowed in *LTS-only* releases and *oldstable* releases are permitted.
|
|
|
- All kinds of fixes are allowed.
|
|
|
- Dirauths _will_ be supported on the network.
|
|
|
In **stable** and **rc** release series:
|
|
|
|
|
|
Additionally, in *alpha* releases:
|
|
|
- All kinds of changes are allowed, not just fixes.
|
|
|
* **NO** new features except for security reasons
|
|
|
* All type of fixes are allowed.
|
|
|
|
|
|
## Implications of these support policies
|
|
|
In **oldstable** release series:
|
|
|
|
|
|
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 in "alpha" and "rc" releases, those releases are where most bugs will be encountered.
|
|
|
Note that old stable are there to allow a transition period to the new stable
|
|
|
and generally not to be used for general use.
|
|
|
|
|
|
In general, users and packagers should try to distribute the "stable" release whenever possible. The "oldstable" status exists so that users and packagers have a grace period in which to migrate from one supported release series to the next.
|
|
|
* Security, Stability and Regression fixes
|
|
|
|
|
|
The LTS-only status is intended to minimize the amount of change to the release over time. Because of that restriction, we cannot promise that an LTS-only release will remain useful or permitted as a client, relay, or onion service on the main Tor network. We will not break an LTS-only release gratuitously (that is, without a good reason) but we can't make commitments beyond that.
|
|
|
In **End-of-Life (EOL)** release series:
|
|
|
|
|
|
## Unstable features
|
|
|
* 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.
|
|
|
|
|
|
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.
|
|
|
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:
|
|
|
|
... | ... | @@ -65,8 +93,6 @@ Examples of unstable features are: |
|
|
* Embedding Tor in another binary.
|
|
|
* Running on [unsupported platforms (Tier 3 or lower)](./SupportedPlatforms).
|
|
|
|
|
|
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.
|
|
|
|
|
|
## Disclaimer
|
|
|
|
|
|
The above policy is our intent, but not a promise. We'll make a solid effort to follow it. |
|
|
\ No newline at end of file |
|
|
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. |