Infra: Link target release to release PEP in PEP 0

[BHUVANSH855]

Summary

This change links Python version entries in PEP 0 to their corresponding release schedule PEPs.

Specifically, it:

• Builds a mapping from Python versions to release schedule PEP numbers using release-topic metadata.
• Emits :pep: references for Python version entries when a matching release schedule PEP exists.
• Falls back to plain text when no matching release schedule PEP is available.
• Adds a regression test covering the new linking behavior.

Testing

python -m pytest
python build.py

Results:

• 532 passed, 2 xfailed
• Documentation build succeeded

Issue

Closes #4379

[read-the-docs-community]

Documentation build overview

📚 pep-previews | 🛠️ Build #33779846 | 📁 Comparing 16a3eac against latest (9bb3132)

  🔍 Preview build  

7 files changed · ± 7 modified

± Modified

• index.html
• numerical/index.html
• pep-0000/index.html
• pep-0764/index.html
• topic/packaging/index.html
• topic/release/index.html
• topic/typing/index.html

[hugovk]

Please also check topic pages such as https://pep-previews--5058.org.readthedocs.build/topic/packaging/, they don't have linked versions.

Is it worth also linking on the release topic page? https://pep-previews--5058.org.readthedocs.build/topic/release/

---

Some with multiple versions don't get linked:

(That "2.6, 3.0" is a link to the joint 2.6/3.0 PEP.)

Add tests to include cases like "2.6, 3.0", "2.7, 3.1" and "2.4, 2.5, 2.6".

[BHUVANSH855]

Thanks! I've updated the topic pages to use the same release_peps mapping as PEP 0 and the numerical index, so the Python version links are now generated there as well.

I've also added regression tests covering the historical multi-version cases you mentioned:

• 2.6, 3.0
• 2.7, 3.1
• 2.4, 2.5, 2.6

I've verified the changes with python build.py and the full test suite (535 passed, 2 xfailed).

[hugovk]

Please check the output, there are still unlinked versions.

[BHUVANSH855]

Please check the output, there are still unlinked versions.

I updated the release PEP mapping to handle release PEPs that cover multiple Python versions (e.g. 2.6, 3.0) by also resolving standalone version lookups when there isn't a dedicated release PEP for that version.

I verified the generated output, and the previously unlinked standalone 2.6 and 3.0 entries are now linked, while existing mappings for versions with dedicated release PEPs (such as 2.7, 3.1, and 3.2) remain unchanged. I also added a regression test for the new mapping logic.

[BHUVANSH855]

Thanks! I've incorporated the suggested simplifications.

• build_release_peps() now stores only individual versions.
• PEPZeroWriter always links versions individually.
• Updated the tests to use real release data and added a case for a version without a release PEP.