Downloads graph should show most popular versions, not most recent

[dhardy]

Consider: https://crates.io/crates/rand/all

The plot currently includes three pre-release versions (0.5.0-pre.*) with very low usage, plus two versions (0.4.2, 0.5.0) accounting for maybe 60% of usage. The older 0.3.22 (still approx 40% usage) isn't even shown.

(Yes, I know it's possible to browse by individual versions, e.g. https://crates.io/crates/rand/0.3.22 )

[djc]

Similar issue for ring right now:

https://crates.io/crates/ring

(Five alpha versions shown, where 80% of downloads are on the latest stable version.)

[sgrif]

The main issue here is that we can't easily determine the "most popular" versions efficiently. We could certainly add a layer of caching to do this, like we did for crates, but I don't know if it's worth doing that for what should be a minority case. I also think that "the most recent version isn't the one people are using" is something that is useful to show.

What if we made sure that pre-release versions always go in "other"?

[djc]

That definitely sounds like an improvement, at least.

[est31]

Regarding pre-release versions, sometimes projects publish them for a long time, making the ecosystem depend on them instead of proper releases. winit and glutin did this for a major semver release. So I think they should be included.

I don't know if it's worth doing that for what should be a minority case.

I think it happens more often than one thinks. Very often, crates have semver breaking versions 0.2x, 0.3.x, and users are distributed among those semver branches. Often, those users run cargo update regularly, so 0.3.0 has almost no users but instead most 0.3.x users are clustered at 0.3.5, the most recent 0.3.x version. Same goes for 0.2.0 vs 0.2.8. The download graph would however list versions 0.3.5, 0.3.4, 0.3.3, 0.3.2, 0.3.0, and hide everything else under "Other". The fact that there are almost no users of versions 0.3.0 until 0.3.4 isn't very helpful, what would be more helpful is showing the user count of 0.2.8 as well as 0.1.4.

This is observable in my lewton crate for example, where Other is a significant category, while 0.10.0 and 0.9.0 are barely used, but Other is quite significant:

As a result, I don't know whether the 0.8.x branch is in use, or 0.7.x, or even older branches.

IMO the ideal solution to resolve @sgrif 's concerns that the most recent version should be shown would be to always include the latest N versions (say latest 2), and fill the remaining 5-N versions with a ranking of most downloads, but still order them by semver ordering.

[joshka]

It's even worse for ratatui (because we do weekly automated alpha releases):

I slapped together a PR that just does the most popular 5 downloads over the 90 days, which is obviously not quite what is discussed. I'm curious about what the real performance of this query might look like. What's the process for testing that against live data?

#9696