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

Whatsnew bad redirection when changing version #138

Open
ThisisYoYoDev opened this issue Oct 26, 2022 · 9 comments
Open

Whatsnew bad redirection when changing version #138

ThisisYoYoDev opened this issue Oct 26, 2022 · 9 comments

Comments

@ThisisYoYoDev
Copy link

Documentation

There is a bad redirection in the documentation in the whatsnew switch between version 3.11. and 3.12.

How to reproduce :

Link to the whatsnew 3.11 -> https://docs.python.org/3.11/whatsnew/3.11.html

image

When we switch to 3.12 we arrive in -> https://docs.python.org/3.12/whatsnew/3.11.html

And we see that this is the wrong redirection.

The link should be -> https://docs.python.org/3.12/whatsnew/3.12.html

I remain at your disposal if you need more details

@kumaraditya303
Copy link

cc @JulienPalard @CAM-Gerlach

@JulienPalard
Copy link
Member

Thanks for opening this issue, it's interesting!

It also happen in any other change of whatsnew, but when "decreasing" the version it lands you on the homepage as the target file does not exist.

The page switch is handled client-side via this function:

=> https://github.com/python/docsbuild-scripts/blob/main/templates/switchers.js#L81

so can you please reopen the issue (and or a PR) on the docsbuild-script repo?

@CAM-Gerlach
Copy link
Member

FYI @JulienPalard , you can simply transfer this issue directly to that repo with the (not easy to spot) Transfer Issue button at the bottom of the right sidebar, without having to recreate a whole new one (I can't as a triager, until the forthcoming permissions workaround is implemented):

image

For me, this is the expected (if not necessarily ideal) behavior, not a "bad redirection" per say—each What's New is its own separate page, and there is no one "current version" What's New page, so naturally switching between different branches gets that branch's version of that What's New page,

What this issue is really requesting is not a bug fix, but rather an enhancement to the behavior of the version switcher, to add special-case logic to more "intelligently" handle switching between "What's New" pages of different Python versions in a way that is more useful to most users. Of course, its more complicated than the issue initially implies, as there are a number of cases to consider and its not completely obvious what the ideal logic should be in every case, but if @JulienPalard thinks its worth it, then it would be an improvement. cc @hugovk

If so, I propose the following logic, in psuedocode:

# If on the What's New for the current Python version,
# Navigate to the selected Python version's What's New page
if current_version == current_whatsnew_version:
    new_whatsnew_version = selected_version
# If the selected version is too early to have the current What's New version
# fall back to the latest What's New version present (i.e. that version's)
elif selected_version > whatsnew_version:
    new_whatsnew_version = selected_version
# Otherwise, just keep the same What's New version, as now
else:
    new_whatsnew_version = whatsnew_version

One possible design for the implementation:

  • Add a function get_whatsnew_version() that takes a url, and returns the capture group in /whatsnew/(\d\d?\.\d\d?), or else null (or some falsely value)
  • Add a function switch_whatsnew_version() that takes the current, selected and what's new versions, .split('.')s them into arrays, applies the above logic (since JS array comparisons appear to work like Python tuple comparisons) and then returns the new what's new version re-knit into a string.
  • Add a function set_whatsnew_version() that takes a url and the new whatsnew_version and returns the the URL with /whatsnew/\d\d?\.\d\d? replaced with the new version.
  • Either stick all those into one function and call it from on_version_switch, or call get_whatsnew_version there and then call the other two in sequence to replace url if the result of the first is truthy

@hugovk
Copy link
Member

hugovk commented Oct 28, 2022

Yeah, I've experienced this and found it a little surprising, albeit logical when you think about it for a moment.

I think the common case would to expect a "sticky" What's New, as suggested.

@JulienPalard JulienPalard transferred this issue from python/cpython Oct 28, 2022
@JulienPalard
Copy link
Member

FYI @JulienPalard , you can simply transfer this issue directly to that repo

Wow thanks!

@JulienPalard
Copy link
Member

I think we all agree that something better can be implemented.

I'm not sure we need to complicate things more than just navigating to f"{selected_version}/whatsnew/{selected_version}.html", after all:

  • It's simple and predictible.
  • The page always exists.
  • If the reader choose a version from the picker while reading a whatsnew, it's highly probable that he wanted to see the choosen version (am I wrong?).

@CAM-Gerlach
Copy link
Member

I certainly understand the desire to not complicate the logic, which was my one concern with this proposal to begin with.

That's essentially what the above proposed implementation boils down to (in perhaps a dozen or so total lines of JS for the whole thing), except that if the reader is browsing a What's New that isn't the current version's, and exists on the target, the What's New version isn't touched, as it wouldn't make sense to arbitrarily change it (given the reader deliberately navigated to that older version, which I would view as a regression).

@ThisisYoYoDev
Copy link
Author

I completely agree with @JulienPalard what I wanted here and what I think everyone wants is to be redirected to the version they want.

When I arrived on the Whatsnew of 3.11 and I saw that the version 3.12 was available in alpha I said to myself I want to see the news about 3.12

So I think the best thing would be to keep it simple like Julien suggested in his message :)

@hugovk
Copy link
Member

hugovk commented Jan 9, 2023

See also python/cpython#100734.

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

No branches or pull requests

5 participants