Repository navigation
feat: announce each release once with a toast generated from the changelog - #618
Conversation
|
Rebased onto current master (1.41.1) and regenerated |
b9fc9f3 to
d18deed
Compare
…ead-ins
The shipped-json test asserted at least one highlight. Many releases are
written without bold lead-ins (1.32.1, 1.29.1 and 1.24.7 here, and every
changesets-bot release whose changesets are plain sentences, this PR's own
changeset included), and the generator handles that on purpose: it warns
and writes an empty list, and the client then stays quiet. Running
`npm run version-packages` in a scratch copy with only this PR's changeset
produced `{"version":"1.42.0","highlights":[]}` and turned the gate red
on exactly the release commit. The version check, which is what keeps a
hand bump from shipping the previous release's notes, stays.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…oup labels
`changeset version` prefixes the first line of every committed changeset
with its commit ("- d18deed: **Lead.** text"), so a changeset that opens
with its bold lead-in, which is the shape the release notes ask for, was
never matched in a changesets-bot release. The pattern now allows that
prefix.
The release notes also put group labels in bold at the start of a line:
"**Fixes.**" and "**Fixes applied while landing.**" (1.41.1, 1.41.0,
1.35.0, 1.33.3). Those were taken as highlights, so a release with few
features announced "... · Fixes applied while landing". They are skipped
like the Thanks block. Tests cover both, and a release with no lead-ins.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
docs/releasing.md step 3 lists everything `npm run version-packages` writes, and the COM commit stages explicit paths, so the new generated file has to be named there: committed with the release, the version check in test/whats-new.test.ts that fails a hand bump (with the two commands that regenerate it), and that a release without bold lead-ins ships an empty list and no toast. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The toast every user sees once per release had no zh-CN entries, so a Chinese interface showed it, button included, in English. The button gets an entry and the frame a translateDynamic pattern that keeps the version, the "(+N more)" count and the highlights (those come from CHANGELOG.md and stay English). Tested through the real i18n.js in JSDOM, plus a pin on the strings settings-ui.js builds, which the pattern depends on. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
feat: announce each release once with a toast generated from the changelog Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The owner chose a minor release. #618's own changeset is folded into the release changeset like the others. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
|
Merged and shipped in 1.42.0. Thanks @opticon454! Keeping this small and quiet by design (one toast per version, silent on a fresh install, generated from the changelog so nobody has to remember it) is what made it an easy yes. Since no browser has the "seen" key yet, the first toast anyone sees will be the one for the release after 1.42.0. Four fixes went in at merge time, each with a test: a release with no bold lead-ins no longer turns the release commit's CI red, a bot-made release's Follow-ups we'd welcome: a downgrade or rollback announces the older release (only announce when the running version is newer than the seen one), inline backticks show up literally in the toast, and two windows opening at the same moment after an update can both show it. |
2 participants
What
A new release announces itself: the first time a browser loads a newer version it shows one toast naming that release's headline changes, with a "See what's new" link to the full notes.
Why
New features and settings arrive in a release and nothing tells the user. It has to happen without anyone remembering to do it each time.
How
scripts/generate-whats-new.mjs(parsing inscripts/lib/whats-new.mjs) takes the current version's section ofCHANGELOG.md, keeps the bold lead-in of each change (the format release notes already use) and skips the Thanks block. It writessrc/web/public/whats-new.json.npm run version-packagesnow runs it, so the file is produced in the release PR with the version bump and the changelog.checkWhatsNew(settings-ui.js) runs on init. It compares the running version withlocalStoragecodeman-whats-new-seen; a never-seen browser records the version silently, so a fresh install is not greeted. Storage blocked, offline or a version mismatch all skip quietly.Tests
test/whats-new.test.ts: section and highlight extraction, the cap, and that the shipped json matchespackage.jsonand is wired into the release script and client. Changeset included.Not in this PR: highlighting individual new settings. That needs a per-change tag in the changeset format, which I would rather agree with the maintainer first.