New tor.git Release and Support Policies
Next week, on April 27th 2022, we'll finally release 0.4.7.x first stable version. This means also that we will branch out from main
and open the merge window for 0.4.8.x series.
I wanted to align this release with this drastic change in our release and support policies:
- Support Policy: https://gitlab.torproject.org/dgoulet/core-team-wiki/-/blob/release-proposal/NetworkTeam/SupportPolicy.md
- Release Policy: https://gitlab.torproject.org/dgoulet/core-team-wiki/-/blob/release-proposal/NetworkTeam/ReleasePolicy.md
The main rationale behind these changes is that simply put our engineering resources have shifted heavily towards arti
(yay!!) and so we need to reduce our workload on tor.git
side. The other reasons, as you'll see below, is the vast importance of a "fast relay upgrade path" for the security and health of the network and thus our users.
There are several noticeable changes from what we do today but two in particular I would like to point out.
- No More LTS
Apart from being a burden because of backports complexity, they are actually a bit of a problem on the relay side of things. We need an healthy network and that implies, in part, to have up to date relays. For security reasons yes but also to take advantage of the new features or defenses we roll out in the latest stable. We are currently suffering 3 to 5 years upgrade path due to LTS versions that lingers in the so call stable OS distributions.
Relay operators MUST stop depending on packages in stable distributions. We have to move our packaging efforts towards deb.torproject.org
, and more agile packaging alternatives like snap
. In other words, our latest stable release must be accessible rapidly to most operators. Keeping an LTS series is counter productive to that.
- Drop the 6 months fixed stable release
As we've seen with 0.4.7.x series, we needed more time to roll out a version that we were satisfied with and high quality. It lead to having a much better and thoroughly tested tor without having an intermediary release with half backed features that for which we then need to maintain for months.
The bottom line here for me currently is simplification of our tor.git processes as it is unrealistic at this point to keep promising our current policies that were design years ago with a much larger team working on tor.git
.