Skip to content

docs(sdk): add deprecation & API stability guide#334

Draft
enyst wants to merge 1 commit intomainfrom
sdk/deprecation-policy
Draft

docs(sdk): add deprecation & API stability guide#334
enyst wants to merge 1 commit intomainfrom
sdk/deprecation-policy

Conversation

@enyst
Copy link
Collaborator

@enyst enyst commented Feb 14, 2026

Summary

Adds a new guide documenting the SDK's deprecation lifecycle and API stability policies.

New file: sdk/guides/deprecation-policy.mdx

What's covered

  1. Public API surface — which packages are covered (openhands-sdk, openhands-workspace) and how __all__ defines the boundary.

  2. Deprecation helpers — usage of @deprecated decorator and warn_deprecated() function from openhands.sdk.utils.deprecation.

  3. Policy: Deprecation before removal — symbols must be deprecated for at least one release before being removed from __all__. Enforced by check_sdk_api_breakage.py.

  4. Policy: MINOR version bump — any breaking change requires ≥ MINOR bump. Enforced by the same script using Griffe.

  5. Policy: Event field deprecation — special handling for Pydantic event models where deprecated field handlers must be permanent to ensure old events always deserialize.

  6. CI checks — summary of check_sdk_api_breakage.py (release PRs) and check_deprecations.py (every PR).

Related PRs

@enyst can click here to continue refining the PR

Document the three deprecation policies enforced by CI:
- Deprecation-before-removal (check_sdk_api_breakage.py)
- MINOR version bump for breaking changes
- Event field deprecation (permanent handlers)

Covers the canonical helpers (@deprecated, warn_deprecated), the
step-by-step removal workflow, and which packages are covered.

Co-authored-by: openhands <openhands@all-hands.dev>
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

Comments