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 #33772607 | 📁 Comparing 4cd9103 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]

2.7 and 3.1 do not share a PEP, they have 373 and 375. They need linking separately.

[BHUVANSH855]

Thanks! I updated the implementation to handle this case by linking individual versions when they don't share the same release PEP (e.g. 2.7 → PEP 373 and 3.1 → PEP 375), while preserving the existing behavior for shared release schedules such as 2.6, 3.0. I also updated the regression test accordingly.

I've pushed the changes, and the full test suite passes (535 passed, 2 xfailed).

[hugovk]

Let's use real test data here: remove the fake {"2.7, 3.1": 375} and {"2.4, 2.5, 2.6": 320} and add a realistic case for 2.4, 2.5, 2.6, and also a version that doesn't exist, like 2.9.

release_peps can be moved out of parametrised tests and can be a hardcoded variable in the setup containing the ones we need.

No need for your agent to tell us the test results, we have a CI for that.

Also we don't use gh-NNNN prefixes outside the CPython.

[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.

[hugovk]

Let's use real test data here: remove the fake {"2.7, 3.1": 375} and {"2.4, 2.5, 2.6": 320} and add a realistic case for 2.4, 2.5, 2.6, and also a version that doesn't exist, like 2.9.

release_peps can be moved out of parametrised tests and can be a hardcoded variable in the setup containing the ones we need.

No need for your agent to tell us the test results, we have a CI for that.

Also we don't use gh-NNNN prefixes outside the CPython.

[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.