Product policy: define support tiers and stability labels for runtimes and public surfaces #158
Description
Summary
gametau now spans multiple runtimes, shims, providers, examples, and generated surfaces. Without a clear support/stability policy, the maintenance burden and public expectations will drift apart.
Why this matters
- Users need to know which surfaces are stable, experimental, or provisional.
- Maintainers need a defensible standard for promotion, deprecation, and support burden.
- A support policy helps keep the project from overcommitting to every plausible runtime/backend idea.
Suggested scope
- Define support tiers for runtimes, providers, and public APIs.
- Define promotion and deprecation criteria.
- Label public surfaces accordingly in docs and package metadata where practical.
Candidate labels
- stable
- experimental
- provisional/internal
Acceptance criteria
- The project publishes a documented support/stability policy.
- Runtimes and major public surfaces are labeled consistently.
- Promotion/deprecation criteria are explicit.
- The policy is reflected in README/site/docs rather than only in issue threads.