Skip to content

Retire/symlink EOL versions? #298

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

Open
AA-Turner opened this issue Apr 16, 2025 · 2 comments
Open

Retire/symlink EOL versions? #298

AA-Turner opened this issue Apr 16, 2025 · 2 comments

Comments

@AA-Turner
Copy link
Member

AA-Turner commented Apr 16, 2025

Currently, 3.0-3.5 and 2.0-2.6 are symlinked to the release/ directory. Should we also retire 2.7, 3.6, 3.7, and 3.8 in the same way?

I'm not sure what procedure @JulienPalard has used in the past, as https://docs.python.org/3.5/ shows the EOL banner even though it is symlinked, meaning the files in release/3.5.10 have changed. We should record what the best course of action is and then apply it to the EOL versions we choose to retire/symlink.

This would also simplify build_docs.py a little bit.

A

adam@docs:/srv/docs.python.org$ ls -al
total 152
drwxrwxr-x  26 docsbuild docs   4096 Oct  7  2024 .
drwxr-xr-x   5 root      root   4096 Aug  8  2024 ..
lrwxrwxrwx   1 docsbuild docs      3 Feb 14  2019 2 -> 2.7
lrwxrwxrwx   1 docsbuild docs     13 Feb 14  2019 2.0 -> release/2.0.1
lrwxrwxrwx   1 docsbuild docs     13 Feb 14  2019 2.1 -> release/2.1.3
lrwxrwxrwx   1 docsbuild docs     13 Feb 14  2019 2.2 -> release/2.2.3
lrwxrwxrwx   1 docsbuild docs     13 Feb 14  2019 2.3 -> release/2.3.5
lrwxrwxrwx   1 docsbuild docs     13 Feb 14  2019 2.4 -> release/2.4.4
lrwxrwxrwx   1 docsbuild docs     13 Feb 14  2019 2.5 -> release/2.5.4
lrwxrwxrwx   1 docsbuild docs     13 Feb 14  2019 2.6 -> release/2.6.9
drwxrwxr-x  19 docsbuild docs   4096 Apr 11  2022 2.7
lrwxrwxrwx   1 docsbuild docs      4 Oct  7  2024 3 -> 3.13
lrwxrwxrwx   1 docsbuild docs     13 Feb 14  2019 3.0 -> release/3.0.1
lrwxrwxrwx   1 docsbuild docs     13 Feb 14  2019 3.1 -> release/3.1.5
drwxrwxr-x  20 docsbuild docs   4096 Apr 15 23:25 3.10
drwxrwxr-x  20 docsbuild docs   4096 Apr 15 23:24 3.11
drwxrwxr-x  19 docsbuild docs   4096 Apr 15 23:22 3.12
drwxrwxr-x  19 docsbuild docs   4096 Apr 15 23:20 3.13
drwxrwxr-x  19 docsbuild docs   4096 Apr 15 23:17 3.14
lrwxrwxrwx   1 docsbuild docs     13 Feb 14  2019 3.2 -> release/3.2.6
lrwxrwxrwx   1 docsbuild docs     13 Feb 14  2019 3.3 -> release/3.3.7
lrwxrwxrwx   1 docsbuild docs     14 Mar 18  2019 3.4 -> release/3.4.10
lrwxrwxrwx   1 larry     larry    14 Sep  5  2020 3.5 -> release/3.5.10
drwxrwxr-x  19 docsbuild docs   4096 Apr 16 01:37 3.6
drwxrwxr-x  20 docsbuild docs   4096 Apr 16 01:35 3.7
drwxrwxr-x  20 docsbuild docs   4096 Apr 15 23:31 3.8
drwxrwxr-x  20 docsbuild docs   4096 Apr 15 23:28 3.9
@JulienPalard
Copy link
Member

I don't remember moving builds to the release folder, and it looks like your ls shows that Larry did.

Anyway, we should be carefull to not break something, I mean if https://docs.python.org/release/2.0.1/ worked it have to work: let's not create 404s.

To keep things as simple as possible we could just replace current symlinks with simple copies.

Next question would be: could (or should?) docsbuild-script automatically archive builds in release/?

I don't know how useufll this folder is.

@AA-Turner
Copy link
Member Author

I don't remember moving builds to the release folder, and it looks like your ls shows that Larry did.

@larryhastings do you recall what you did here? Looks like it was in 2020, though, so a while ago!

Anyway, we should be carefull to not break something, I mean if docs.python.org/release/2.0.1 worked it have to work: let's not create 404s.

To keep things as simple as possible we could just replace current symlinks with simple copies.

Indeed, my proposal is not to change any of the release/ links, but instead to delete the symlink e.g. /3.6/ to /release/3.6.15, meaning that it is 'retired' from docsbuild-scripts, and just kept as a simple static archive, with no further rebuilds. The question is how best to ensure that we keep the EOL banner, etc.

From #294:

[Hugo]
Do we need to rebuilt EOL versions at all?

[Julien]
It's always a good idea to be able to do so:

  • To add the EOL banner (once).
  • To update the sidebar maybe.
  • To update any other thing that we would need to update like meta tags, or I don't know.

I think for EOL versions that are still in /srv/docs.python.org/, we should ensure we can rebuild them. As shown though (#294, #295), this is increasingly tricky, especially before 3.8 when the requirements.txt file was introduced.

My preference for EOL versions would be to remove the switchers (which will become out of date) and instead use the banner and sidebar to redirect people to current stable. Those that still need to use EOL documentation will (I presume) use direct links. There is some precedent for this, as e.g. the 3.4 documentation has no switchers.

A

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

2 participants