Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/pkgsite: search ranking ought to prioritize more recent major module versions #36969

cespare opened this issue Feb 1, 2020 · 6 comments


Copy link

@cespare cespare commented Feb 1, 2020

What is the URL of the page with the issue?

What is your user agent?



For example, search for "xxhash":


What did you do?

Searched for "xxhash"

What did you expect to see?

The v2 module should be ranked above the old v1 module even if the v1 module has more importers or otherwise ranks higher according to the heuristics uses.

Even better, IMO, the v1 wouldn't even show up as a separate search result. The module would appear once and if you visit the page you would see the v2 by default with a way to browse the older module versions.

What did you see instead?

The v1 module appears as the first search result, encouraging new users to use an old version of my module rather than the new one.

@myitcv myitcv added the pkgsite label Feb 2, 2020
Copy link

@myitcv myitcv commented Feb 2, 2020

Copy link

@jba jba commented Jun 8, 2020

I'm uncomfortable showing v2 when v1 is more popular. Perhaps v2 is a misfire, and v1 is the better module (see New Coke).

I do think we should group all versions of a module together. Perhaps we can sort that subgroup by version, but mark the most popular in some way (or vice versa—sort by popularity and mark the latest—which I think I like better).

@julieqiu julieqiu changed the title search ranking ought to prioritize more recent major module versions x/pkgsite: search ranking ought to prioritize more recent major module versions Jun 15, 2020
@julieqiu julieqiu added the UX label Jun 15, 2020
@julieqiu julieqiu removed this from the Unreleased milestone Jul 31, 2020
@julieqiu julieqiu added this to the pkgsite/design-2020 milestone Jul 31, 2020
@julieqiu julieqiu removed this from the pkgsite/design-2020 milestone Aug 19, 2020
@julieqiu julieqiu added this to the pkgsite/search milestone Aug 19, 2020
Copy link
Contributor Author

@cespare cespare commented Sep 19, 2020

@jba or maybe the reason that v1 is more "popular" is because most people who go looking for the package end up using v1 due to the poor discoverability of later major versions.

As both a consumer and maintainer of open source projects, I prefer nudging toward later major versions. Any popular module that introduces a new major version will go through a long period where more people are using the older version. That doesn't mean that new users should prefer the older version. (And nudging toward "most used" is self-reinforcing: it might be hard for a newer version to catch up if the old version is still adding new users this way.)

Copy link

@rogpeppe rogpeppe commented Dec 8, 2020

I agree with @cespare: I think the latest non-prerelease-tagged major version should always be the main result. If it's not, then no-one will ever be likely to move to a new major version even when there's a strong need to do so, because the old version will always take precedence. Older versions will almost always be more popular, just because they've been around for longer. The author of the package is publishing a new major version specifically because they want people to change to use it.

However, it's reasonable that the most popular version could also have some prominence, because compatibility with other dependencies can also be a consideration.

Here's a screenshot of some recent results:


It's clear that the major version plays no role at all in sorting the results, not even as a secondary sort key after popularity.
In fact, because of the nature of the particular package above, it's likely that almost all the uses are in closed source projects, so popularity is not a good guide.

Copy link

@mvdan mvdan commented Dec 8, 2020

Perhaps v2 is a misfire

If a new major version was a mistake that should be ignored, wouldn't those versions be retracted?

Copy link

@julieqiu julieqiu commented Aug 20, 2021

This will be addressed #47321 (specifically #47320 and #47839), so closing this issue.

@julieqiu julieqiu closed this Aug 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants