|
# Releases
|
|
# Support policy
|
|
|
|
|
|
Network team is responsible for Core Tor releases, we aim to have a new release
|
|
```
|
|
every 6 months.
|
|
DRAFT DRAFT DRAFT
|
|
|
|
|
|
Please check our [Release Guidelines](./ReleaseGuidelines) for more
|
|
This isn't policy yet.
|
|
detailed information on the process.
|
|
```
|
|
|
|
|
|
Please check our [Release Parameters](./ReleaseParameters) for more
|
|
## Kinds of releases
|
|
detailed information on what protocol version or consensus parameters will
|
|
|
|
affect the network.
|
|
|
|
|
|
|
|
## Support policy
|
|
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.
|
|
|
|
|
|
Releases can either be "regular" or "long-term support" ("LTS"). Regular
|
|
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.
|
|
releases are supported for 9 months after they become stable or for 3 months
|
|
|
|
after the next release becomes stable -- whichever is longer. LTS releases are
|
|
|
|
supported for some time announced in advance -- typically, 3 years.
|
|
|
|
|
|
|
|
For all supported releases, we intend that:
|
|
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.
|
|
|
|
|
|
* Information needed to connect to the Tor network (directory authorities, fallback directories, geoip tables) will be kept up-to-date.
|
|
## Levels of support
|
|
* Important security issues will get fixed.
|
|
|
|
* Major stability issues will get fixed.
|
|
|
|
* Portability regressions will get fixed.
|
|
|
|
* Portability bugs to major supported platforms will get fixed.
|
|
|
|
|
|
|
|
For the most recent supported stable release only, we intend that:
|
|
In *unsupported* release series:
|
|
|
|
* No changes are made.
|
|
|
|
* No new versions are released.
|
|
|
|
* Nothing is promised.
|
|
|
|
|
|
* Misleading documentation will get fixed.
|
|
In *all supported release series*:
|
|
* Smaller bugs that significantly impact user experience will get fixed.
|
|
* We update _data_ that is required or recommended for connecting to the Tor network, including authority lists, fallback directory lists, and geoip configuration.
|
|
|
|
|
|
We do NOT expect:
|
|
Additionally, in *LTS-only* releases:
|
|
|
|
* We fix security bugs that cause vulnerabilities.
|
|
|
|
* We apply _simple_ patches only 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 don't make other changes.
|
|
|
|
|
|
* That unsupported releases will all work on the Tor network.
|
|
Additionally, in *oldstable* releases:
|
|
* That unsupported releases will all fail to work on the Tor network.
|
|
- All patches allowed in *LTS-only* releases are permitted.
|
|
* That older supported releases will provide the same privacy as the newer ones.
|
|
- 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.
|
|
|
|
|
|
Some features and configurations are currently only maintained in the two most
|
|
Additionally, in *stable* and *rc* releases:
|
|
recent stable releases, either because they are less mature than the rest of
|
|
- All patches allowed in *LTS-only* releases and *oldstable* releases are permitted.
|
|
Tor, because there are relatively few users who need them, or for some other
|
|
- All kinds of fixes are allowed.
|
|
reason:
|
|
- Dirauths _will_ be supported on the network.
|
|
|
|
|
|
|
|
Additionally, in *alpha* releases:
|
|
|
|
- All kinds of changes are allowed, not just fixes.
|
|
|
|
|
|
|
|
## Implications of these support policies
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
## 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:
|
|
|
|
|
|
* Running a directory authority.
|
|
|
|
* Enabling Rust support.
|
|
* Enabling Rust support.
|
|
* Enabling NSS support.
|
|
* Enabling NSS support.
|
|
* Embedding Tor in another binary.
|
|
* Embedding Tor in another binary.
|
|
* Getting volunteer-submitted patches to run on [unsupported platforms (Tier 3 or lower)](./SupportedPlatforms).
|
|
* 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. |
|
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 |