Pre-flight checklist
Problem or use case
The repository's own README.md headlines "New in 1.11.0" and CHANGELOG.md's top entry is 1.11.0 (with two different dates stated for it in the same file), while the documentation site is on 1.14.1 (2026-05-28) — roughly three minor versions ahead. For a project whose entire stabilization story depends on trustworthy semver and release notes (the stability promise is literally "no breaking changes between minor releases for Stable modules; breaking changes for Beta/Experimental are flagged in the Release Notes"), a CHANGELOG that lags the published version by three minors undermines the credibility of every stability claim and leaves adopters unable to verify what changed when.
Proposed solution
Reconcile the in-repo README.md and CHANGELOG.md with the published 1.12.x–1.14.x releases, fix the conflicting dates on the 1.11.0 entry, and adopt a per-module stability changelog so each release explicitly records module status transitions (e.g., "media: Beta → Stable") and any flagged breaking changes per module. This is the documentation/DX backbone that makes the entire road-to-stable auditable. Consider adding a single Stability Matrix source of truth referenced by both the README and the docs site so they cannot drift again.
Possible API or UX shape
## 1.14.1 — 2026-05-28
### Module status
- media: Beta → Stable
- forms: Beta (API frozen, targeting Stable in 1.15)
### Breaking changes (Beta/Experimental, per policy)
- ssr: renderToStream chunk signature changed — migration: …
Alternatives considered
Maintaining release notes only on the docs site — but the repo is where contributors and dependents look first, and the drift is already causing a credibility gap. Keeping a single flat changelog without per-module status — works, but per-module status transitions are exactly what this stabilization effort needs to communicate.
Relevant area
docs
Additional context
Not glamorous, but it is a prerequisite for the stabilization effort to be believable: every promotion ticket above asserts an API freeze, and there must be an accurate, single-source changelog where those freezes and transitions are recorded. Could alternatively be filed under "build or tooling" if release automation is added to prevent future drift.
Pre-flight checklist
Problem or use case
The repository's own
README.mdheadlines "New in 1.11.0" andCHANGELOG.md's top entry is 1.11.0 (with two different dates stated for it in the same file), while the documentation site is on 1.14.1 (2026-05-28) — roughly three minor versions ahead. For a project whose entire stabilization story depends on trustworthy semver and release notes (the stability promise is literally "no breaking changes between minor releases for Stable modules; breaking changes for Beta/Experimental are flagged in the Release Notes"), a CHANGELOG that lags the published version by three minors undermines the credibility of every stability claim and leaves adopters unable to verify what changed when.Proposed solution
Reconcile the in-repo
README.mdandCHANGELOG.mdwith the published 1.12.x–1.14.x releases, fix the conflicting dates on the 1.11.0 entry, and adopt a per-module stability changelog so each release explicitly records module status transitions (e.g., "media: Beta → Stable") and any flagged breaking changes per module. This is the documentation/DX backbone that makes the entire road-to-stable auditable. Consider adding a single Stability Matrix source of truth referenced by both the README and the docs site so they cannot drift again.Possible API or UX shape
Alternatives considered
Maintaining release notes only on the docs site — but the repo is where contributors and dependents look first, and the drift is already causing a credibility gap. Keeping a single flat changelog without per-module status — works, but per-module status transitions are exactly what this stabilization effort needs to communicate.
Relevant area
docsAdditional context
Not glamorous, but it is a prerequisite for the stabilization effort to be believable: every promotion ticket above asserts an API freeze, and there must be an accurate, single-source changelog where those freezes and transitions are recorded. Could alternatively be filed under "build or tooling" if release automation is added to prevent future drift.