Skip to content

Centralize deprecation version markers in DeprecatedSince - #3444

Draft
deruyter92 wants to merge 5 commits into
jaap/remove-rst-filesfrom
jaap/deprecation-versions-constants
Draft

Centralize deprecation version markers in DeprecatedSince#3444
deruyter92 wants to merge 5 commits into
jaap/remove-rst-filesfrom
jaap/deprecation-versions-constants

Conversation

@deruyter92

Copy link
Copy Markdown
Collaborator

Summary

Add DeprecatedSince to deeplabcut/core/deprecation.py, holding one constant per
round of deprecations, and points all 67 markers across 33 files at it:

@deprecated(replacement="deeplabcut.core.config.ProjectConfig", since=DeprecatedSince.CONFIG_MODEL_MIGRATION)

Add a test that walks the package and fails on any remaining since= or
removed_in= literal, so the single source of truth holds without relying on review.
deprecation.py is exempt: its docstrings illustrate the API with literal versions.

@C-Achard C-Achard left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few comments, note that the suggestions for additional dataclasses only matter if we want some sort of fancy automated ingestion, for maintaining it is likely redundant.

Feel free to cherry pick what you like and ignore the rest!

Comment thread deeplabcut/core/deprecation.py Outdated
Comment thread deeplabcut/core/deprecation.py Outdated
Comment thread deeplabcut/core/deprecation.py Outdated
Comment thread deeplabcut/core/deprecation.py
@C-Achard C-Achard added enhancement New feature or request documentation documentation updates/comments labels Aug 13, 2026
@C-Achard C-Achard added this to the v3.0.2 milestone Aug 13, 2026
add test keeping version literals out of deprecation markers
Walks the shipped package and fails on any since= or removed_in= literal, so
DeprecatedSince stays the single source of truth. deprecation.py is exempt:
its docstrings illustrate the API with literal versions.
Also checks that every constant parses as a version.
Every @deprecated and @renamed_parameter marker spelled its version inline, so
a round of deprecations could only be retargeted by grepping for version
strings across the codebase. That is how the 3.1 -> 3.0.1 sweep in #3422 missed
analyze_time_lapse_frames, and it makes it easy to move an unrelated API while
retargeting one round.
DeprecatedSince now holds one constant per round, named after the migration
rather than its version so a retargeted round keeps its name, and annotated
with the PR that introduced it. All 67 markers reference it.
@deruyter92
deruyter92 force-pushed the jaap/deprecation-versions-constants branch from 4e6f30b to 3c819f4 Compare August 13, 2026 14:17
@deruyter92

Copy link
Copy Markdown
Collaborator Author

@C-Achard Applied all your suggestions, thanks for the review.

Note, I've rebased the PR to make it better reviewable (and fixed the commit messages).

class DeprecationRound(Enum):
"""Collection of all deprecation rounds used in the deprecation markers - single source of truth."""

PARAMETER_CONSISTENCY = DeprecationRoundInfo(

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another quick comment, we may want to think about disambiguation, I can foresee many times where we might need to deprecate for parameter consistency. Maybe some sort of year/month marker ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation documentation updates/comments enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants