[metrics-bugs] #21427 [Metrics/Onionoo]: allow to filter for tor_version

[Tor Bug Tracker & Wiki]

#21427: allow to filter for tor_version
-----------------------------+-------------------------------
 Reporter:  cypherpunks      |          Owner:  metrics-team
     Type:  enhancement      |         Status:  merge_ready
 Priority:  Medium           |      Milestone:  Onionoo-1.4.0
Component:  Metrics/Onionoo  |        Version:
 Severity:  Normal           |     Resolution:
 Keywords:                   |  Actual Points:
Parent ID:                   |         Points:
 Reviewer:                   |        Sponsor:
-----------------------------+-------------------------------

Comment (by karsten):

 Replying to [comment:6 iwakeh]:
 > Replying to [comment:5 karsten]:
 > > Replying to [comment:3 iwakeh]:
 > > > All checks and tests pass now with the two small commits on
 [https://gitweb.torproject.org/user/iwakeh/onionoo.git/log/?h=task-21427
 this branch].
 > >
 > > Thanks for the review and those two additional commits.
 > >
 > > > Could it be confusing to use use 'version' as search key name,
 because actually the 'platform' field of the details document is used and
 there are fields that contain the word 'version'?
 > >
 > > Wait, we're only looking at the last part of the "platform" line:
 >
 > True.  Maybe, use "platform_version", which is kind of long?

 Wait, no, we're not using the "platform" line from server descriptors, but
 we're using the [https://gitweb.torproject.org/torspec.git/tree/dir-
 spec.txt#n2142 "v" line from consensuses], and that only contains the
 version. So, "version" is probably more accurate.

 > > ...
 > >
 > > And which other fields are there that contain the word "version" which
 might confuse users?
 >
 > In details we have "recommended_version".  Maybe, rather keep 'version'
 (b/c it is short) and document it well.

 Yes, I think that's good.

 > > Let's eliminate any confusions before merging. (But we'll also have to
 be careful not to call the parameter "platform" if we don't look at the
 entire platform string.)
 > >
 > > > Other than that: merge ready.
 > >
 > > One thing, though: Should we briefly talk about possible extensions to
 support multiple versions or version ranges? How about
 `"version=0.3.0,0.3.1"` (all 0.3.0 and 0.3.1 versions),
 `"version=0.2.4.21-0.2.4.29"` (everything between 0.2.4.21 and 0.2.4.29),
 `"version=0.2.9-"` (0.2.9 or higher), `"version=-0.2.9999`" (everything up
 to 0.2.9999), etc.?
 > >
 > > (Note that in particular the ranges might lead to surprises when used
 in two-digit version numbers; for example, `"version=0.2.4.2-0.2.4.3`"
 matches 0.2.4.2, 0.2.4.3, but also 0.2.4.21. I'm not sure whether we can
 do anything about that without getting into the business of parsing
 version strings.)
 >
 > I would wait and not implement this, as there are not enough sub-
 versions that would justify such an effort.  And, we offer a range search,
 because `search=version:0.2` returns all versions 'in between'/'below',
 i.e., `0.2`, `0.2.1.1`, `0.2.2.1`, etc.

 Agreed. Note, however, that if we decide to make such extensions in the
 future, they'll be backward-incompatible (requiring a new major version),
 because we're currently accepting searches like `0.1.2.3-alpha`, which
 would conflict with the `0.1.2.3-0.1.2.6` notation. But, I'm fine with
 that.

 Alright, will merge tomorrow unless there are objections.

 > > > I'll add a ticket for documentation update.
 > >
 > > (Thanks!)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21427#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online