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.

Start by reviewing the existing ReST versionchanged and versionadded directives and how they render version values. Define a syntax and rendering behavior for multiple versions, including backported security fixes and filtering future versions; done means the documentation displays each applicable release without manual ambiguity.