Downloads graph should show most popular versions, not most recent

[dhardy]

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

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

[dhardy]

This is still as much an issue for rand as it ever was.

Suggestion

I suggest always showing the following (where they exist):

• The latest two releases (where distinct from the below)
• The latest non-pre-release version
• The previous patch release for the above
• The second most-recent non-pre-release MAJOR.MINOR version
• The previous patch release for the above
• Other

That's a maximum of seven plots, of which at most two will use pre-release versions.

Alternative

Hide pre-releases older than the latest non-pre-release, both on the graph and on the crate-versions page, adding a checkbox to "Show all versions".

[joshka]

Can you add some color on the reasons for those specific items? (Mostly because it would help in presenting options that work well across the ecosystem if the rationale was grounded rather than the result). My guess is that it's in aid of supporting maintainer like questions like:

• how many people are still using previous major version?
• how many people moved to the pre-releases before I did a major bump?
• where are the sticking points with people not upgrading?

Here's rands graph with a bit of a different criteria playing around locally with some ideas for this (default version, latest, previous, > 10% downloads, Top N to fill leftover)

[joshka]

Hey to whoever marked #4336 (comment) as spam - there's real analysis in that. human in the loop, realistic validated conclusions with data that measured the impact of the suggestions for what to show instead of the latest 5 options, as well as a few extra options to see if there were any significantly better ideas for displaying this data. The methodology is based on actual significant amounts of data. Anyway, the result is that the best result came from choosing the top 6 by download count with a preference to show stable rather than pre-release versions generally.