Skip to content

Follow-up: require deprecation marker for intentional SDK API removals #2066

@enyst

Description

@enyst

After merging PR #1098 (SDK API breakage detection via Griffe), consider adding a follow-up policy check:

Goal: For intentional breaking changes (e.g., removing a symbol from openhands.sdk.__all__), require evidence that it was previously deprecated, instead of only enforcing a MINOR bump.

Notes / options:

  • Griffe itself detects structural breakages, but it does not inherently encode deprecation semantics. To enforce this, we’d need a canonical deprecation marker that is statically inspectable.
  • Possible approaches:
    1. Standardize on a decorator/annotation/docstring tag (e.g., @deprecated, typing_extensions.deprecated, or a specific docstring directive) and have the CI check assert that any removed exported symbol had that marker in the previous release snapshot.
    2. Alternatively, implement a runtime shim alias that warns on import/use for >=1 release, and enforce presence via a separate static check (grep/AST) rather than Griffe.
    3. Provide an explicit waiver mechanism for exceptional cases.

Acceptance criteria:

  • CI fails when an exported symbol is removed but there is no detectable deprecation marker in the previous release.
  • CI continues to pass for non-removal breakages with the existing MINOR bump rule (unless we decide otherwise).

Refs: PR #1098

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions