zoriya/v10
1
0
Fork 0
mirror of https://github.com/zoriya/v10.git synced 2026-08-11 08:29:47 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs(site): backfill and prose-ify beta changelogs (#1794)

Browse Source 
Co-authored-by: Claude <noreply@anthropic.com>
This commit is contained in:
Darius Cepulis
2026-07-02 16:15:18 -07:00
committed by GitHub
co-authored by Claude
parent 854df60fcb
commit e060cf0d54
25 changed files with 174 additions and 361 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/workflows/changelog-prose.yml
+13 -10
View File
@@ -125,23 +125,26 @@ jobs:
- Some PR numbers may resolve to null — skip those gracefully.
3. **Rewrite the changelog body:**
- Replace the raw bullet list with narrative prose (100–300 words).
- Lead with the 1–3 most impactful changes, informed by epic/issue context.
- Group related PRs into cohesive stories rather than listing them individually.
- Call out breaking changes explicitly with migration guidance if applicable.
- Summarize smaller fixes briefly.
- Skip internal-only changes (CI, tooling, changelog maintenance).
- Replace the raw bullet list with narrative prose. Length scales with content: substantial releases get 100–300 words; small releases (a few bullets) get 1–3 honest sentences. Never pad to hit a word count.
- Write paragraphs only: no headings, bullet lists, or tables. Use backticks for identifiers (e.g., `deps.alwaysBundle`, `<media-gesture>`).
- Lead with the 1–3 most impactful changes, informed by epic/issue context. Vary the opening; do not default to "This release…".
- Group related PRs into cohesive stories rather than listing them individually (e.g., a feature landing across core, html, and react is one story with three links).
- Call out breaking changes explicitly with concrete migration guidance from the PR body (old name → new name, what to update). Do not bury them.
- Summarize smaller fixes briefly, grouped.
- Skip internal-only changes (CI, tooling, changelog maintenance) — unless the release is entirely internal, in which case describe it honestly in a sentence or two rather than leaving the body empty.
- Preserve PR links as inline markdown links in the prose (e.g., [#906](url)). Every change you mention keeps its PR link.
- Drop per-change author credits ("by @user") — the PR link carries attribution.
- If the raw file has a "New Contributors" section, remove it and end the prose with one sentence thanking first-time contributors by name, linking their GitHub profiles.
- Follow `writing-style.md` strictly.
- Preserve PR links as inline markdown links in the prose (e.g., [#906](url)).
- Do not fabricate — stick to what the PRs actually say.
4. **Write the `description` field:**
- One sentence summarizing the release for SEO/RSS.
- Update the `description: ""` field in the file's YAML frontmatter.
- One concise sentence starting with a verb, summarizing the release for SEO/RSS (e.g., "Adds a hotkey system, gestures, and the mux-audio element."). Keep it under 140 characters.
- Update the `description: ""` field in the file's YAML frontmatter. Change nothing else in the frontmatter.
5. **Create a PR:**
- Create branch: `docs/changelog-prose-${{ steps.version.outputs.version }}`
- Stage and commit the changed file: `docs(changelog): add prose for ${{ steps.version.outputs.version }}`
- Stage and commit the changed file: `docs(site): add changelog prose for ${{ steps.version.outputs.version }}` (commitlint's scope-enum has no `changelog` scope, so use `site`)
- Push the branch and open a PR targeting `main`.
- Include a link to the release in the PR body.
- Keep the PR description concise.