The theory is that you would review it as you upgrade to each new release, at which time it would be up to date and you wouldn’t have to trawl back through older documents. (Note that I don’t agree with this theory.)
A single page would be great. Someone has to maintain it, and if you want it to be versionless, it needs a home that is outside the CPython docs.
+1 on the single page idea. This would allow users to better plan their upgrades and needed development effort for this (companies tend to skip Python releases due the upgrade effort getting in the way with regular development).
Perhaps an informational PEP could help with this, as this would not be tied to the Python release cycle.
It’s still in the design and very early prototype phase, but I’ve been slow-burn working on tooling to extract additions, changes and deprecations programmatically from the CPython docs (perhaps cross referenced with other sources as well, such as the docstrings, What’s New and dynamic inspection of the actual code), that might provide at least a basis for constructing such a page (as part of a broader system), especially if we enrich our existing custom deprecated-removed directive to include some additional metadata, much of which I also propose in the soft deprecation thread. I can’t promise immediate results here, but I’m very excited about all the potential things this could unlock.