I wonder if there was some automation we can add to help ensure that planned deprecations actually happen? Like, maybe a JSON file or some such where the deprecations are recorded (or a script to parse the docs or code). Then, when the new version is created at main, the automation would open some release blockers on those deprecations. What do you think?

@warsaw Probably, grepping docs for .. deprecated-removed:: and headers for Py_DEPRECATED would be better than maintaining another list file.

Edit: for \.\. deprecated-removed:: [^ ]+ (\d+).(\d+) and Py_DEPRECATED\((\d+).(\d+)\).

I wonder if there was some automation we can add to help ensure that planned deprecations actually happen?

Yes, using the new warnings._deprecated method will make it clear with RuntimeErrors after the relevant alpha: https://discuss.python.org/t/introducing-warnings-deprecated/14856

I wonder if there was some automation we can add to help ensure that planned deprecations actually happen?

See also:

• Enforce the use of deprecated-removed in docs #92564
• Add support for future-version workflows core-workflow#468

I wonder if there was some automation we can add to help ensure that planned deprecations actually happen?

You could also fire a Sphinx warning in the else branch here in the directive (with a check for whether its an alpha, and perhaps an :option: to disable it for special cases), just like warnings._deprecated does.

Will try again in a new PR :)

Please see PR #108055 instead 🚀