Tor version support policy v2

I'm starting this as a fresh page, since it's pretty much entirely a rewrite.

Goals

There are 4 questions we need to answer, from just a Tor development POV, ignoring all bundling issues for now:

• Which Tor versions do we support?
• To what degree to we support them?
• What operating systems do we try to run on, and how hard do we try?
• Which library versions do we try to tolerate?

User goals:

• Users should be able to answer the above questions clearly.
• Users should always have a genuinely stable release to run that works fine on the network.
• Given that transitions between release series can be more destabilizing than transitions within a release series, conservative users should have a reasonably broad window in which to see if a new stable series is stable enough for them before they upgrade.
• Every user wants Tor to work on their operating system.
• Users should not get their operating system unsupported by surprise.

Distributor goals:

• Distributors want to know (at least) how long a stable series is going to get bugfixes for.
• Distributors don't want to include Tor in their releases unless it's going to

Developer goals:

• Developers don't typically want to waste their time by maintaining compatibility features that aren't necessary.
• Developers want to know which versions of Tor they need to keep the current version of Tor working with
• Developers who find a longstanding bug (say, "bugfix on 0.0.9pre8") want to know which version to write their patch against. If they write it against too early a version, they're wasting time, but if they write it against too late a version, they'll have to realize later that it needs a backport, and backport it.
• Developers don't want to have too many series going at once.
• Developers want to know when they can refactor code and rip out unnecessary compatibility gunk.
• Developers want to know which sets of APIs they can assume.

Bundler goals:

• Bundlers don't want to have too many active versions to make packages for.
• Bundlers want to make bundles that people actually use.
• Bundlers want to know in advance which bundles they'll have to build.

Tor version policy

A tor version is of the form x.y.z.w-status. The x.y.z part (such as 0.2.2) is a "release series".

A release series can be in one of 4 states: Alpha, Latest, Legacy, or Obsolete.

• The current alpha series is 0.2.3.x. New features and bugfixes go into the alpha series. There is only one alpha series at a time.
• The latest series is the most recent series in feature freeze or later. It gets every bugfix that seems likely to improve user experience, given a reasonable cost in time and risk. It does not get new features, except under exceptional circumstances. The current latest series is 0.2.2.x.
• Older supported series are legacy. They only get those bugfixes that are needed for a secure, stable, well-behaved network. Currently, 0.2.1.x is legacy.
• Obsolete releases are older still. They get no bugfixes at all. Tor 0.2.0.x and earlier are obsolete.

Discussion: The designation "latest" encompasses everything from the first alpha in which the feature freeze is declared, through the earlier stable releases in the series. Note that, in practice, the first "stable" release in a given series does not mark the point at which the series more stable than the one before. A conservative user typically waits for a few stable versions to come out before upgrading.

How long is a series supported?

Here is what we do in practice:

• In practice, we have tended to support a series for about 2 years after it is declared stable. To make Debian happy with putting Tor in with its more nonvolatile packages, we would probably need to say "3 years". I do not know if we can.
• In practice, we are very bad at keeping two legacy releases at once.

Proposed policy, option 1:

• We could say, whenever we release a new series as stable, "We will keep this series supported for the next N years." Proposed policy, option 2:
• We could say, whenever we release a new series as stable, "We will keep this series X supported until X+M goes into feature freeze."

For M==2 and N==2, these policies tend to work out to about the same result. The first one gives more predictability to distributors; the second one makes life easier for developers.

What do we build bundles of?

We do not need to build bundles for all non-obsolete series. The most important series to build branches for are:

• The latest series.
• The most stable legacy series.
• The alpha series.

What about operating system support?

There are three reasons to support an operating system:

• Because our developers are productive coding on/for them
• Because lots of relay operators like to user them
• Because lots of users have them

The main reasons (other than lack of the positive reasons above) not to support an operating system are:

• It's not getting any support from its vendor
• It's hard to develop for it.

We should never break OS compatibility or drop OS support in a stable series: If 0.5.5.20-stable supports Windows 7, then every 0.5.5.x should support Windows 7.

For operating systems that are free and fairly easy to upgrade, we should not spend much effort supporting the ones that the vendors do not support. This includes all the free unixes.

For non-OSX commercial unixes, our support tends to be "give us a patch when we break Tor on your OS".

Our main open questions on OS support are: when may we drop support for a Windows release or an OSX release? Our previous policy has been: "approximately never" or "only when unavoidable" or "if we do it by accident and nobody complains, that's cool". I suggest that instead we come up with some better criteria, and actually consider dropping Windows 98.

What about library support?

Tor's required libraries are libevent, openssl, and zlib.

Windows gives us none of these, so we need to include them, so we can generally use whatever libraries we want.

For OSX, we need to work with all OpenSSL and zlib versions are shipped on versions of OSX we support.

For other operating systems, we generally have to work with the openssl and zlib and libevent they give us.

This means that our oldest supported non-windows OS determines which library versions we must support.

Tor currently requires:

• OpenSSL >0.9.7
• zlib > 1.2
• libevent >= 1.0

I believe that we may safely drop support for Libevent pre-1.3e.