a2ui-project / a2ui-project/a2ui

Define a status taxonomy for renderers (parallel to spec version taxonomy from #1240)

Ouverte Adaptée aux débutants
#1,321 5 commentaires 2 réactions 0 personnes assignées Voir sur GitHub
component: specification P2 type: feature/enhancement
Langage dominant
TypeScript
Étoiles
16.4k
Forks
1.3k
Merge moyen
2 j 13 h
PR mergées (30 j)
134

Description

Follow-up from #1302 (review thread between @ditman and me).

#1240 settled on a clear taxonomy for **specification versions**: `draft` / `candidate` / `final` / `deprecated`. We don't have an equivalent for **renderers**, and the [Roadmap](https://github.com/google/A2UI/blob/main/docs/roadmap.md) currently uses an informal mix:

- ✅ Stable — Web Core Lib, Lit, Angular, Flutter, Markdown, React
- 📋 Planned — Jetpack Compose, SwiftUI
- 💡 Proposed — Vue, Svelte, ShadCN

@ditman raised the question: should we replace `Stable` with `Available` or similar? I pushed back on `Available` (loses the maturity signal — a freshly-shipped renderer is "available" the moment it's published, indistinguishable from one hardened by users for a year). But `Stable` is also imperfect pre-1.0.

### Options to consider

1. **Mirror the spec taxonomy** — `draft` / `candidate` / `stable` / `deprecated`. Couples renderer maturity to the spec version it targets. Conceptually clean; reuses vocabulary contributors already learned.
2. **OSS-standard ladder** — `alpha` / `beta` / `stable` / `deprecated`. Most renderers would currently be `beta` since we're pre-1.0. Honest but might feel like a downgrade.
3. **Available / Planned / Proposed** (@ditman's suggestion) — Simple, flat, no maturity signal.
4. **Hybrid** — Use the spec taxonomy for renderer↔spec compatibility (per spec version), and a separate maturity label per renderer overall.

### Things to decide

- Single status per renderer, or status per (renderer × spec version) cell? (The reference table is already 2D today.)
- Do we want a "recommended" / "latest" signal, or is that implied by the table ordering?
- Should the labels live in `docs/glossary.md` next to the spec version taxonomy?

cc @polina-c @ditman @jacobsimionato

Guide de contribution

Ouvrir le guide de contribution

Piste de recherche

Review the spec version taxonomy defined in issue #1240 and the current renderer statuses in docs/roadmap.md. The glossary file docs/glossary.md is the likely place to add the new taxonomy. Compare the proposed options and decide on a consistent labeling system for the renderer table. The change is textual and conceptual, not code.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
typescript
Domaine
documentation
Type d'issue
Documentation
Difficulté
2/5
Temps estimé
1-3 heures
Activité
Calme
Clarté
Clairement spécifiée
Accessibilité débutants
65/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.