René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"[Feature]: Reconcile version history and add a per-module stability changelog","articleBody":"**Pre-flight checklist**\n- [x] I searched existing issues and did not find a duplicate request.\n- [x] I explained the problem or use case, not just the desired API.\n\n**Problem or use case**\nThe 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.\n\n**Proposed solution**\nReconcile 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.\n\n**Possible API or UX shape**\n```\n## 1.14.1 — 2026-05-28\n### Module status\n- media: Beta → Stable\n- forms: Beta (API frozen, targeting Stable in 1.15)\n### Breaking changes (Beta/Experimental, per policy)\n- ssr: renderToStream chunk signature changed — migration: …\n```\n\n**Alternatives considered**\nMaintaining 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.\n\n**Relevant area**\n`docs`\n\n**Additional context**\nNot 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.\n","author":{"url":"https://github.com/JosunLP","@type":"Person","name":"JosunLP"},"datePublished":"2026-06-26T21:26:02.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/150/bQuery/issues/150"}