Repository navigation
Allow .. versionadded:: next in docs #121277
Description
Activity
It might be better for the tool to live outside the cpython repo, like blurb.
Reacted by Hugo van KemenadeIt might be better for the tool to live outside the cpython repo, like blurb.
The tool for replacing version "next" in .rst files with the number makes sense to keep in repo to me (as your draft PR does for now) as it is small. Really not a lot more than could be done with some inscrutable
sedcommands.It's small, but there can still be bugs in it, and it'd be easier to deal with those if we don't need to backport them.
@hugovk You said elsewhere that you'd prefer the version-bumping tool to live outside CPython repo. Since it's so small, I'd add it (and its test) to https://github.com/python/release-tools directly. Would that work?
You're a RM, so you get to choose the bikeshed paint here :)
Reacted by Éric, Gregory P. Smith, Pradyun Gedam and Adam Turner@hugovk You said elsewhere that you'd prefer the version-bumping tool to live outside CPython repo. Since it's so small, I'd add it (and its test) to python/release-tools directly. Would that work?
Yep, this sounds good 👍 🖌️
- added a commit that references this issue
on Sep 26, 2024 3 remaining items
It's now in 3.13 & 3.12. I plan to wait for releases from those branches before offering this to RMs of the security-only ones. (This is obviously not a security fix, but as a feature designed to make backporting easier, it might get an exception.)
Yup!
Pre-releases and dot-0's do have slightly different behaviour though.Reacted by Hugo van KemenadeŁukasz's decision on backporting to 3.9, and then updating the devguide.
Reacted by Adam TurnerDevguide PR open: python/devguide#1503
With that, I'll close this issue. Thank you everyone for feedback & reviews!
Reacted by Adam Turner and Hugo van Kemenade- added a commit that references this issue
on Feb 9, 2026
Feature or enhancement
Proposal:
In a PR to CPython, the
versionadded,versionchanged,versionremoved,deprecated,deprecated-removeddirectives in documentation should currently be set to the upcoming release.This is inconvenient:
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:
versionadded& the others to expand the version argumentnextto<version> (unreleased)(e.g.3.14.0b0 (unreleased)).nextwith a given string (e.g.3.14).(unreleased). The RM should be able to skip this test, in case of a false positive.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
Linked PRs
.. versionadded:: nextin docs #121278nextas second argument to deprecated-removed #124623.. versionadded:: nextin docs (GH-121278) #124718.. versionadded:: nextin docs (GH-121278) (GH-124718) #125980Related PRs
nextversions in docs by the just-released version release-tools#164nextin versionadded & similar directives devguide#1413Discourse announcement