-
-
Notifications
You must be signed in to change notification settings - Fork 30.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow .. versionadded:: next
in docs
#121277
Comments
It 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 |
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 :) |
Yep, this sounds good 👍 🖌️ |
…version See: python/cpython#121277 This PR gives the RM a tool to replace all such occurences of `next` by the currently released version, baking it directly into the ReST source files, as part of the version bump commit. This is done textually (I don't know of a round-trip parser for ReST). To make sure the text manipulation worked, the released docs artifact (if it's being published) is grepped for the string `(unreleased)`, and if it's found, the RM is asked for confirmation.
Make `versionchanged:: next`` expand to current (unreleased) version. When a new CPython release is cut, the release manager will replace all such occurences of "next" with the just-released version. (See the issue for release-tools and devguide PRs.) Co-authored-by: Adam Turner <[email protected]> Co-authored-by: Hugo van Kemenade <[email protected]>
* main: (69 commits) Add "annotate" SET_FUNCTION_ATTRIBUTE bit to dis. (python#124566) pythongh-124412: Add helpers for converting annotations to source format (python#124551) pythongh-119180: Disallow instantiation of ConstEvaluator objects (python#124561) For-else deserves its own section in the tutorial (python#123946) Add 3.13 as a version option to the crash issue template (python#124560) pythongh-123242: Note that type.__annotations__ may not exist (python#124557) pythongh-119180: Make FORWARDREF format look at __annotations__ first (python#124479) pythonGH-58058: Add quick reference for `ArgumentParser` to argparse docs (pythongh-124227) pythongh-41431: Add `datetime.time.strptime()` and `datetime.date.strptime()` (python#120752) pythongh-102450: Add ISO-8601 alternative for midnight to `fromisoformat()` calls. (python#105856) pythongh-124370: Add "howto" for free-threaded Python (python#124371) pythongh-121277: Allow `.. versionadded:: next` in docs (pythonGH-121278) pythongh-119400: make_ssl_certs: update reference test data automatically, pass in expiration dates as parameters python#119400 (pythonGH-119401) pythongh-119180: Avoid going through AST and eval() when possible in annotationlib (python#124337) pythongh-124448: Update Windows builds to use Tcl/Tk 8.6.15 (pythonGH-124449) pythongh-123884 Tee of tee was not producing n independent iterators (pythongh-124490) pythongh-124378: Update test_ttk for Tcl/Tk 8.6.15 (pythonGH-124542) pythongh-124513: Check args in framelocalsproxy_new() (python#124515) pythongh-101100: Add a table of class attributes to the "Custom classes" section of the data model docs (python#124480) Doc: Use ``major.minor`` for documentation distribution archive filenames (python#124489) ...
) Make `versionchanged:: next`` expand to current (unreleased) version. When a new CPython release is cut, the release manager will replace all such occurences of "next" with the just-released version. (See the issue for release-tools and devguide PRs.) Co-authored-by: Adam Turner <[email protected]> Co-authored-by: Hugo van Kemenade <[email protected]> (cherry picked from commit 7d24ea9)
…recated-removed (pythonGH-124623) (cherry-picked from e349f73)
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:
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 argumentnext
to<version> (unreleased)
(e.g.3.14.0b0 (unreleased)
).next
with 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:: next
in docs #121278next
as second argument to deprecated-removed #124623.. versionadded:: next
in docs (GH-121278) #124718Related PRs
next
versions in docs by the just-released version release-tools#164next
in versionadded & similar directives devguide#1413Discourse announcement
The text was updated successfully, but these errors were encountered: