Skip to content

docs(style): a docstring is not a changelog - #587

Merged
breimanntools merged 1 commit into
masterfrom
doc/no-version-history-in-docstrings
Sep 18, 2026
Merged

breimanntools merged 1 commit into
masterfrom
doc/no-version-history-in-docstrings

Conversation

@breimanntools

Copy link
Copy Markdown
Owner

The style guide said ".. versionchanged:: X.Y.Z when behaviour changes" and offered the parameter-level form only as an alternative. Agents followed it literally: a 2026-06-01 pass (a4537eed) backfilled version history into docstrings package-wide, and the API pages now open with a stack of "Changed in version 1.1.0" blocks before the reader learns what the method does.

Measured on origin/master: 242 versionadded + 40 versionchanged across the package, 11 of the latter in _cpp.py alone. CPP.__init__'s docstring went 36 → 102 → 117 lines across v1.0.3 → v1.1.0 → today, and the version stack is part of why.

The rule now

  • exactly one .. versionadded:: per public symbol, marking when the symbol appeared
  • never a .. versionchanged:: stack at class or method level
  • a behaviour change is annotated on the parameter that changed — the scikit-learn placement
  • everything else lives in CHANGELOG.md and the release notes, which is where a reader looking for history goes

Mirrored into .claude/rules/docstrings.md, so it reaches an agent before it writes the docstring, with the numbers included — the previous wording is exactly what produced them.

No library code touched and no existing docstring edited here. The cleanup of the 40 existing entries is tracked in #581, which carries the rendering target and the one decision it needs (whether the class-level versionadded is worth keeping at all).

🤖 Generated with Claude Code

The guide said "`.. versionchanged:: X.Y.Z` when behaviour changes" and
offered the parameter-level form only as an alternative. Agents followed it
literally: a 2026-06-01 pass backfilled version history into docstrings
package-wide, and the API pages now open with a stack of "Changed in
version 1.1.0" blocks before the reader learns what the method does.

Measured: 242 `versionadded` + 40 `versionchanged` across the package, 11
of them in _cpp.py. `CPP.__init__`'s docstring went 36 -> 102 -> 117 lines
across v1.0.3 -> v1.1.0 -> today, and the version stack is part of why.

The rule is now: exactly one `versionadded` per public symbol, marking when
the symbol appeared; never a `versionchanged` stack at class or method
level; a behaviour change is annotated on the parameter that changed, and
otherwise lives in CHANGELOG.md and the release notes, which is where a
reader looking for history goes.

Mirrored into .claude/rules/docstrings.md so it reaches an agent before it
writes the docstring, with the numbers, since the previous wording is
exactly what produced them.

No library code touched; no existing docstring edited here.

Co-Authored-By: Claude Fable 5.1 <[email protected]>
@codecov

codecov Bot commented Sep 18, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.39%. Comparing base (3c11c90) to head (d93b612).

Additional details and impacted files

Impacted file tree graph

@@           Coverage Diff           @@
##           master     #587   +/-   ##
=======================================
  Coverage   95.39%   95.39%           
=======================================
  Files         222      222           
  Lines       23387    23387           
  Branches     4073     4073           
=======================================
  Hits        22309    22309           
  Misses        631      631           
  Partials      447      447           
Components Coverage Δ
cpp_core 95.97% <ø> (ø)
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@breimanntools
breimanntools merged commit fc8e21e into master Sep 18, 2026
22 checks passed
@breimanntools
breimanntools deleted the doc/no-version-history-in-docstrings branch September 18, 2026 21:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant