[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #24256 [Metrics/Onionoo]: Add a new "outdated" field to distinguish between outdated and too new tor versions
#24256: Add a new "outdated" field to distinguish between outdated and too new tor
versions
-----------------------------+-----------------------------------
Reporter: arma | Owner: metrics-team
Type: enhancement | Status: needs_information
Priority: Medium | Milestone:
Component: Metrics/Onionoo | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
-----------------------------+-----------------------------------
Comment (by karsten):
I took a brief look at
[https://gitweb.torproject.org/tor.git/tree/src/or/routerparse.c#n1132
tor_version_is_obsolete()] today. Quite a few cases there. Before I looked
at that code I somehow assumed that we could divide the non-recommended
bucket into outdated and experimental and be done with it. But it seems
like we'd also need an unknown bucket and maybe even more.
If that's really the case we might want to avoid adding separate boolean
fields for all possible statuses, like `"outdated_version":true`,
`"experimental_version":false`, etc., and instead introduce a new string
field like `"version_status":"outdated"` with pre-defined values like
`"recommended"`, `"outdated"` (or `"obsolete"`?), `"experimental"`,
`"unknown"`, etc.
Does that make sense? What statuses would we need, and how would we call
them to avoid confusing users when a client application decides to present
version status values directly to its users?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24256#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs