[metrics-bugs] #24256 [Metrics/Onionoo]: Add a new "outdated" field to distinguish between outdated and too new tor versions

Tor Bug Tracker & Wiki blackhole at torproject.org
Sat Nov 18 20:42:44 UTC 2017


#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


More information about the metrics-bugs mailing list