-
-
Notifications
You must be signed in to change notification settings - Fork 62
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
Comments
I don't remember moving builds to the release folder, and it looks like your 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 I don't know how useufll this folder is. |
@larryhastings do you recall what you did here? Looks like it was in 2020, though, so a while ago!
Indeed, my proposal is not to change any of the From #294:
I think for EOL versions that are still in 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 |
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
The text was updated successfully, but these errors were encountered: