# Feature or enhancement ### Proposal: In a PR to CPython, the `versionadded`, `versionchanged`, `versionremoved`, `deprecated`, `deprecated-removed` directives in documentation should currently be set to the upcoming release. This is inconvenient: - the numbers need to be changed in backports - if a PR misses a feature release, the number needs to be updated It would be good to treat this more like News entries, which live in a `next/` directory before a release, when the release manager bundles them up and assigns a version. Concrete proposal: - [x] Teach `versionadded` & the others to expand the version argument `next` to `<version> (unreleased)` (e.g. `3.14.0b0 (unreleased)`). - [x] Add a tool that replaces the `next` with a given string (e.g. `3.14`). - [x] Modify the release manager tooling to run the tool on release. - [x] Add a check to release manager tooling that *built* HTML documentation for a fresh release does not include the string `(unreleased)`. The RM should be able to skip this test, in case of a false positive. - [x] Update the Devguide. - [x] Announce in Discourse ### Has this already been discussed elsewhere? I have already discussed this feature proposal on Discourse ### Links to previous discussion of this feature: https://discuss.python.org/t/automating-versionadded-changed-markers-in-docs-to-expedite-prs/38423 <!-- gh-linked-prs --> ### Linked PRs * gh-121278 * gh-124623 * gh-124718 * gh-125980 * gh-127827 * gh-127867 * gh-128117 <!-- /gh-linked-prs --> ### Related PRs * release-tools PR: https://github.com/python/release-tools/pull/164 * devguide PR: https://github.com/python/devguide/pull/1413 ### Discourse announcement * https://discuss.python.org/t/versionadded-next/65280