Hmmm, I like parts of this a lot- the way we currently manually document deprecations only in the changelog for the version it first appears in makes this horrible for users to assemble, but would also be an absolute nightmare for us to maintain manually…
Referencing our push to make long-running non-atomic code tasks declarative/SSOT over on 8/12, and thinking about the granular warning control stuff we’ve been kicking around, this seems like something we should be able to generate pretty easily directly from the code as part of that work using the same extraction mechanisms that the deprecation sanity tests use. I’d be happy to trade more detailed inline declarative descriptions of deprecations for manually crafted changelog/porting guide entries on those things- especially if we could tie it in with the “externally linked documentation in error/deprecation/warning” stuff.
I’m less sure about how workable the second half of that ask might be to generate, but might be doable in, e.g., the non-versioned community docs build, pulling from the same declarative metadata we’d cough up for the “all pending deprecations in this release”.