TLDR: There appears to be a mismatch between the support policy [1] vs. actual expectations from torproject people,
it would be beneficial to clarify and update the policy and documentation to avoid similar situations
(different expectations and understandings of what EOL means in the context of the torproject)
in the future and so we and others can learn from it and hopefully prevent it from happening again.
Shortly after the release and feedback in this thread I added a note to the release information about delaying the upgrade to relayor v26.2.0
if the operator runs relays across more than one /16 IPv4 or /32 IPv6 network.
ahf wrote:
When a release goes EOL, we have a period where we can work with
other people and partners, who are in contact with us, about their
use of Tor. During this time, we can hint to them at upgrading. Some
of the reasons for upgrading are new features, safety, and security
issues. We are not in a hurry at all here.
It is clear now - after the emails in this thread - that some have expectations that go
beyond the end-of-life date of a tor release series.
1) The current support policy does not document the mentioned stages after the EOL date.
The current support policy [1] from Jul 19, 2022 describes these stages:
-> alpha
-> release candiate (rc)
-> stable
-> oldstable
-> end-of-life
So according to that policy the last event in the lifecycle of a tor release series is the end-of-life date.
End-of-life releases are unsupported and "You are on your own.":
[1]:
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.
Most notably [1] and [2] do not say anything about the mentioned additional stages beyond the end-of-life date,
in the specific case of 0.4.8 the stage between 2026-06-01 - 2026-09-01 and the stage after 2026-09-01.
2) Clarifying [1] with the mentioned expectations would be beneficial
I also created a gitlab issue for this under:
a) EOL meaning
Since the term "end-of-life" already has a certain meaning in the software world Software release life cycle - Wikipedia
I think it is best do not create a torproject specific meaning of "end-of-life" to avoid similar confusion in the future.
The "oldstable" description [1]:
Note that old stable are there to allow a transition period to the new stable
and generally not to be used for general use.
somewhat matches what ahf described ("During this time, we can hint to them at upgrading. Some of the reasons for upgrading are new features, safety, and security issues.")
to some degree.
b) Scope
I would also suggest to add scope information to the support policy to make the scope/roles of the policy clear (clients, onion services, relays, bridges, dir auths, ...)
because the current version includes wording that would suggest that it is only about relays by using terms like "the directory authorities might reject them from the consensus"
because clients are not in the consensus.
A pointer for arti's support policy would be good if it is not on the same page.
c) document non-mutual expectations
If the torproject expects relay operators to support tor client versions for a longer period of time
than the torproject it self supports them, then make that clear in the expectations for relay operators document [3] by pointing to [2].
An updated version of [2] could help relay operators find out the specific date until when they must support a specific tor series.
Currently it does not include such information (for example the 2026-09-01 date for 0.4.8.x).
Without explicit information many will believe it is fine to drop support as soon as the torproject declares them unsupported.
It is probably confusing for relay operators if they get removed from the tor network for using a end-of-life tor version
while also getting removed from the tor network for NOT supporting EOL version clients.
3) more proactive communications / announcements
On 2026-04-13 I asked about the EOL date [10] and suggested a blog post announcement, no reaction to the email was observed before the EOL date on 2026-06-01
but I noticed related gitlab activity after that email.
On my side:
- I will start proactive information for similar relayor changes but they were very rare in the past (1x in 10 years?).
- I might create a support policy for relayor - blocked until the torproject support policy changes are completed.
- I'll announce similar changes on my mastodon feed before they take place and are released.
kind regards,
nusenu
Some pointers to policies/documents, feel free to add more if you notice any relevant page missing:
[1] SupportPolicy · Wiki · The Tor Project / Core / Team · GitLab
[2] CoreTorReleases · Wiki · The Tor Project / Core / Team · GitLab
[3] Expectations for relay operators - The Tor Project - Policies
[4] Relay EOL policy · Wiki · The Tor Project / Network Health / Team · GitLab
[5] ReleasePolicy · Wiki · The Tor Project / Core / Team · GitLab
[6] TROVE · Wiki · The Tor Project / Core / Team · GitLab
[7] DeprecationTorPhases · Wiki · The Tor Project / Core / Team · GitLab
[8] Recommended Tor versions policy - The Tor Project - Policies
[9] Reject relays running unsupported Tor versions even if the series is not EOL yet (#149) · Issues · The Tor Project / Network Health / Team · GitLab
[10] [tor-relays] tor version 0.4.8.x end of life date? - tor-relays - lists.torproject.org
···
--
_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org
