Bug: Dead "Release notes" links on the download page for old releases

[petersuttondev]

Describe the bug

"Release notes" links on the Downloads page for releases 3.3.6 and before are broken. Example link:

https://hg.python.org/cpython/file/v3.3.6/Misc/NEWS

To Reproduce

1. Go to Downloads pages https://www.python.org/downloads/
2. Click "Release notes" for a release before 3.3.6

Expected behavior

Should navigate to the release notes for that release.

URL to the issue

https://www.python.org/downloads/

Screenshots

Browsers

Firefox

Operating System

Linux

Browser Version

No response

Relevant log output

Additional context

No response

[KoentjoroFIG]

Hi, I’m new to open‑source contributions and thought this issue would be a good place to start. I’d like to confirm the right approach before submitting a fix.

Here’s my reasoning:

1. hg.python.org has been retired since hgweb was shut down.
2. The affected links should now point to docs.python.org.

For example,
https://hg.python.org/cpython/file/v3.3.6/Misc/NEWS

should be updated to

https://docs.python.org/release/3.3.6/whatsnew/changelog.html

My question is: should this update be made by editing downloads.json directly, or is it preferred to create a migration file for this change?

Thanks for the guidance!

[jenaarmaan]

Hi,

Thanks for the detailed investigation above — that aligns with what I’m seeing as well.

I’m happy to take this up once the preferred approach is confirmed.
In the meantime, I can start identifying all affected releases and mapping them to their corresponding docs.python.org changelog URLs so the fix is complete and consistent.

Please let me know if that sounds reasonable. Thanks!

[nagasrisai]

Hi team! 👋 I've submitted a fix for this in PR #2965.

Root cause: The release_notes_url field for old releases (3.3.6 and earlier) stores URLs pointing to hg.python.org (the old Mercurial host), which now returns 404. The same content is available on GitHub at the same relative path.

Fix: Added a corrected_release_notes_url property to the Release model that detects hg.python.org URLs and remaps them to their github.com/python/cpython equivalents. No database migration needed — the stored values are left unchanged. The downloads index template is updated to use the corrected URL and also gains a graceful fallback for empty URLs.

4 unit tests cover all cases: hg→GitHub conversion, https variant, modern URLs unchanged, and empty URL passthrough.

PR: #2965

[merwok]

I don’t know if that’s the correct way to fix. If these URLs are stored in the database, then someone with editor permissions can go into the CMS and change them.

(General note: if you use chatbots to generate code or comments, please disclose it — see policy in devguide.)

[nagasrisai]

Thanks for the note, @merwok. That makes sense — if an editor can update the records directly in the CMS that's definitely simpler than adding a property to the model. I wasn't sure whether that was the preferred path or whether a code-level fix was expected, so I went with the latter. Happy to close the PR if a direct database update is the right way to go. Should I look into how to do that instead, or is that something the team handles on the admin side?

[merwok]

We should wait for a pydotorg editor to see this and give feedback.

[hugovk]

This affects some 78 releases. This editor isn't keen on manually editing that many, so a programmatic approach is the way to go :)

[petersuttondev]

I'm happy to create an automatic data migration to fix the source data. Then we don't need a bodge in the Python.

[nagasrisai]

Good to know on the scale ,78 releases is definitely too many to touch by hand, glad the programmatic route makes sense.

@petersuttondev if you're up for writing the migration that works for me. If it's easier, I can also update PR #2965 to use a data migration instead of the model property — happy either way, just don't want to duplicate effort. Let me know how you'd like to split it.