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

Closed
cespare opened this issue Feb 1, 2020 · 6 comments
Closed
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. pkgsite/search Issues related to pkg.go.dev search functionality pkgsite UX Issues that involve UXD/UXR input

Comments

@cespare
Copy link
Contributor

cespare commented Feb 1, 2020

What is the URL of the page with the issue?

https://pkg.go.dev/search

What is your user agent?

N/A

Screenshot

For example, search for "xxhash":

https://pkg.go.dev/search?q=xxhash

screen_20200201123259

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 pkg.go.dev 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
@myitcv
Copy link
Member

myitcv commented Feb 2, 2020

Related #36806 (comment)

@julieqiu julieqiu added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 2, 2020
@gopherbot gopherbot added this to the Unreleased milestone Feb 6, 2020
@jba
Copy link
Contributor

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 go.dev: 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 Issues that involve UXD/UXR input label Jun 15, 2020
@cespare
Copy link
Contributor Author

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.)

@rogpeppe
Copy link
Contributor

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:

image

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.

@mvdan
Copy link
Member

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?

@julieqiu
Copy link
Member

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

@hyangah hyangah added the pkgsite/search Issues related to pkg.go.dev search functionality label May 20, 2022
@golang golang locked and limited conversation to collaborators May 20, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. pkgsite/search Issues related to pkg.go.dev search functionality pkgsite UX Issues that involve UXD/UXR input
Projects
None yet
Development

No branches or pull requests

8 participants