Skip to content

Design review: contrib adapter policy and support tiers #32

@aatuh

Description

@aatuh

Context

Contrib adapters and integrations are maintained outside the stable core API promise. Supported-adapter status should be useful to adopters without implying root-module stability.

Review paths

  • ROADMAP.md
  • docs/contrib-adapters.md
  • docs/adapter-maturity.md
  • docs/package-classification.tsv
  • docs/supported-adapter-contracts.tsv
  • docs/supported-adapter-test-realism.tsv
  • VERSIONING.md

Questions

  • Are supported-adapter, experimental, wrapper-only, generated, and tooling tiers clear enough?
  • What evidence should be required before promoting an adapter to supported-adapter?
  • Is the contrib drift policy strong enough without overstating compatibility guarantees?
  • Which contrib adapters need clearer production caveats or external-service realism evidence?

Desired outcome

A recommendation for contrib support policy, including any tier wording, evidence, or release-review changes needed before broader adoption.

Metadata

Metadata

Assignees

No one assigned

    Labels

    help wantedExtra attention is neededquestionFurther information is requested

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions