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: prefer directing the user to the same package in the highest tagged major version #42292

Open
mvdan opened this issue Oct 30, 2020 · 6 comments

Comments

@mvdan
Copy link
Member

@mvdan mvdan commented Oct 30, 2020

When I navigate to https://beta.pkg.go.dev/mvdan.cc/sh/syntax, clicking on "The highest tagged major version is v3" takes me to https://beta.pkg.go.dev/mvdan.cc/sh/v3, not https://beta.pkg.go.dev/mvdan.cc/sh/v3/syntax.

I guess this is fine as a fallback, if v3/syntax doesn't exist as a package. But if the same sub-package exists in the new major version of the module, I think we should directly link there. Otherwise I have to go into "directories" and find it again.

Split off from #41588 (comment). CC @julieqiu

@mvdan mvdan added the pkgsite label Oct 30, 2020
@gopherbot gopherbot added this to the Unreleased milestone Oct 30, 2020
@julieqiu
Copy link
Contributor

@julieqiu julieqiu commented Oct 30, 2020

If anyone is interested in working on this, we'd love to accept a contribution for this feature!

The current implementation always looks for the highest major version of the module:
https://github.com/golang/pkgsite/blob/98f3bcc459fdc73d18ee7cad633696139c7be97b/internal/postgres/version.go#L110

We could use the paths.v1_path column, like in GetVersionsForPath to determine the highest major version for a package.

@mvdan
Copy link
Member Author

@mvdan mvdan commented Oct 30, 2020

We could use the paths.v1_path column, like in GetVersionsForPath to determine the highest major version for a package.

Hmm, I don't agree there. If I'm in /v2/foo, the latest major version of the module is v4, and /v3/foo exists but /v4/foo does not, I still think we should point the user towards v4 and not v3.

The detail is that the link should be to /v4/foo if the package exists there, and if the package does not exist, we can fall back to linking to /v4. Falling back to /v3/foo seems like a worse option, because then the user might not even notice that v4 is probably what they should use instead.

@julieqiu
Copy link
Contributor

@julieqiu julieqiu commented Oct 30, 2020

If I'm in /v2/foo, the latest major version of the module is v4, and /v3/foo exists but /v4/foo does not, I still think we should point the user towards v4 and not v3.

@mvdan I agree this should be the behavior.

My comments in #42292 (comment) are suggestions for how to get started, in case anyone is interested in working on this issue.

@Catzkorn
Copy link

@Catzkorn Catzkorn commented Nov 23, 2020

Hi @julieqiu & @mvdan

I'd like to work on this issue, it will be my first contribution to the Go project. Is there anything else I need to do to claim this issue?

@julieqiu
Copy link
Contributor

@julieqiu julieqiu commented Nov 23, 2020

Nope, all yours! Check out the CONTRIBUTING.md for how to get started. If you have questions, feel free to reach out in the #pkgsite channel on Gophers slack.

@Catzkorn
Copy link

@Catzkorn Catzkorn commented Nov 24, 2020

Great! Thank you Julie :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.