Skip to content

Establish a deprecation policy for the 0.x series #6

@alialavia

Description

@alialavia

Problem

The README currently says "APIs are unstable and may change without deprecation warnings until 0.x stabilizes." That's an honest statement but it's also a license to break consumers without warning, which gets uncomfortable as alpha users actually start adopting.

Proposal

Once we hit 0.2 (or whichever feels stable enough), commit to a soft policy:

  • Renames go through one minor's worth of `DeprecationWarning` before removal.
  • Behavior changes for already-public functions ship behind a feature flag for one minor.
  • New optional parameters with sensible defaults are not breaking and need no warning.
  • Strict breaking changes (signature, semantics) get a major-version bump even pre-1.0.

Acceptance

  • `CHANGELOG.md` "Known limitations" section is updated to reflect the policy.
  • A short paragraph in the README links to the changelog instead of saying "no policy".
  • A 0.x → 1.0 graduation checklist is captured (e.g., GitHub milestone) so we know what's left.

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentation

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions