Docs need support for a multiversion changed/added marker.

Documentation

We have .. versionchanged:: NUMERIC TEXT and .. versionadded:: NUMERIC TEXT support in our ReST docs.

But I believe it must be a single numeric value/word to render meaningfully? What we lack is the less commonly needed ability to specify multiple versions at once. Typically for a subset of security fix backports.

Today's common practice has been to just list the relevant version from the branch being committed to (example: in main 3.12 today, in 3.11: 3.11.99, etc.) with a manual change to the docs required within each backport PR.

This is somewhat unsatisfactory for documentation readers: People often link to and read the latest /3/ docs on the website regardless of the Python version they are using. Where a version marker saying something happened in a specific release often ignores that the change was back-ported to older releases. Meaning people may not realize that unless they happen to bother loading the older version specific documentation.

note: Adding multi-version support in the tags wouldn't address the manual PR change on back-port issue (references to future versions in changed/added markers don't belong there... unless we could we auto-filter those out based on version number at doc compilation time?) - but that, or better, automating initial version population into those fields from the surrounding codebase, belongs in a separate feature request.

Commencez par examiner les directives ReST existantes versionchanged et versionadded, ainsi que la manière dont elles affichent les valeurs de version. Définissez une syntaxe et un comportement de rendu pour plusieurs versions, notamment les correctifs de sécurité rétroportés et le filtrage des versions futures ; le travail sera considéré comme terminé lorsque la documentation affichera chaque release applicable sans ambiguïté manuelle.