Public Changelog

The Changelog is a public "What's new" page on your feedback board. Entries flow in from three sources — hand-written updates, synced GitHub releases, and completed feature requests — but your users see one curated stream. Nothing goes live until you publish it.

Key Features

• One stream, three sources — Write entries by hand, sync them from GitHub releases, or let completed feature requests draft themselves.
• Draft gate — Every ingested entry lands as a draft. You review, polish, and publish; only published entries appear publicly.
• Release blocks — Entries that share a component and version render under one version header, so a release with five changes reads as one release.
• Components — Tag entries with the product asset they belong to (CLI, Dashboard, React SDK, …). Rendered as colored chips, with filter tabs on the public page — one stream, many assets (see Components).
• Categories — Optional "Keep a Changelog"-style labels (Added, Improved, Fixed, Changed, Removed, Security) with filter pills on the public page.
• Permalinks — Every entry has its own shareable page with entry-specific title and description for link previews.
• Atom feed — Subscribers can follow your changelog from any feed reader or RSS-driven integration (Slack, Discord, Zapier).
• Email digest — Visitors can opt in to a weekly email summary of new entries, sent from your own domain (see Email digest).
• Reactions — Visitors can react to entries (👍 🎉 ❤️ 🚀) without signing in — lightweight engagement signal per update.
• Widget badge — The feedback widget shows a "News" badge when there are updates the visitor hasn't seen yet.
• Closes the loop — A completed feature request on the board links to its changelog entry ("See what shipped"), and the entry links back to the original request.

Accessing the Changelog

# Public page
https://seggwat.com/p/YOUR_PROJECT_KEY/changelog

# A single entry (shareable permalink)
https://seggwat.com/p/YOUR_PROJECT_KEY/changelog/ENTRY_ID

# Atom feed (for feed readers and integrations)
https://seggwat.com/p/YOUR_PROJECT_KEY/changelog/feed.xml

The Changelog tab appears on your board automatically once you publish your first entry — publishing is the opt-in. You can hide the tab any time via Settings > Public Board > Show changelog tab.

Sources and the Draft Gate

Every entry carries a status:

Status	Public	Meaning
Draft	No	Awaiting review. Default for new and synced entries.
Published	Yes	Live on the public changelog.
Hidden	No	Soft-hidden; preserved but off the public stream.

Manual entries

Write entries in Changelog in your project sidebar. The editor supports Markdown with a live preview, an optional version badge, a category, a component, and an optional display date — use the date to backdate entries when importing your existing changelog history.

GitHub releases

With the GitHub integration connected, the changelog page shows a release-sync card:

• Auto-sync as drafts — every published GitHub release becomes a changelog draft (title from the release name, version from the tag, body from the release notes, dated to the release).
• Sync now — pull releases on demand.
• Component rules — map release-tag prefixes to components for monorepos that ship several assets from one repo (see Components).

Sync is instant when your GitHub App delivers release webhook events, and a sweep also runs every six hours as a fallback. Sync never duplicates a release and never overwrites an entry you've edited — each release is ingested once, as a draft, and from then on it's yours.

Components

If your changelog covers more than one product asset — a CLI, a dashboard, an SDK — define components on the changelog manage page. Each component is a name plus a chip color; entries tagged with one show a colored chip next to the category badge, and your public changelog gains filter tabs (All · CLI · Dashboard · SDK) while staying a single stream. Untagged entries appear under All only.

This replaces encoding the asset into the version string: instead of react-v1.2.0, an entry is tagged React SDK with version v1.2.0. Two components can ship the same version number without their entries merging into one release block.

Tag-prefix rules for GitHub sync. Monorepos usually ship prefixed tags (v1.2.0, react-v0.5.0, tour-v2.0.0). In the release-sync card, add rules like react- → React SDK and pick a default component for unmatched tags — synced drafts then arrive pre-tagged, with the matched prefix stripped from the version badge. The longest matching prefix wins. Rules only apply to new syncs; the Apply to existing button tags entries that don't have a component yet (it never overrides one you've set).

Per-component feeds. The Atom feed accepts a component filter, so a reader can follow just one asset:

https://seggwat.com/p/YOUR_PROJECT_KEY/changelog/feed.xml?component=cli

Completed feature requests inherit a component automatically when one of the request's tags has the same name as a component — tag your ideas "CLI" and a CLI component picks them up.

Completed feature requests

When you mark a feature request as Completed, SeggWat asks for the version it shipped in and drafts a changelog entry from the request (using your admin response when present, otherwise the request description). Publish it and the request's card on the public board gains a "See what shipped" link.

Publishing

• Publish / Unpublish per entry, or Publish all to clear a batch of drafts after a release sync.
• The first publish stamps the entry's display date (unless the entry already carries one — synced releases keep their release date, backdated imports keep their date). Re-publishing keeps the original date.
• Delete is permanent and asks for confirmation — prefer Hide if you might want the entry back.

Email digest

Not everyone lives in a feed reader. The changelog can also email a weekly digest of your newly-published entries to visitors who opt in — the 1:many counterpart to the per-feedback "we shipped your request" email.

Enable it under Settings > Notifications > Changelog Email Digest. Once on, the Subscribe popover on your changelog page gains an email field; the RSS feed and per-entry permalinks are unchanged.

How it works

• Double opt-in — a visitor enters their email and clicks a confirmation link before anything is sent. The confirmation is the consent record.
• Weekly, never empty — one digest a week (Tuesday), and weeks with no new entries are skipped entirely. Multiple entries shipped in a week arrive in a single email.
• One-click unsubscribe — every digest carries a one-click List-Unsubscribe header and a footer link.

Requirements & deliverability

The digest is bulk email, so it always sends from your own domain via a custom email sender (a Pro feature) — never the shared SeggWat relay. To land in inboxes:

• Use a bulk-tolerant SMTP provider (Amazon SES, Mailgun, Resend Broadcasts). Avoid Gmail/Workspace SMTP and transactional-only streams — they cap or flag bulk sending.
• Authenticate your domain with SPF, DKIM, and DMARC.

Managing via API and MCP

The changelog has a full REST surface — list, create (with backdating), update, publish, and delete entries programmatically. See the Changelog API reference.

If you've connected SeggWat to Claude via MCP, the assistant can curate your changelog end-to-end: list_changelog, create_changelog_entry, update_changelog_entry, and set_changelog_status — all component-aware, so agent-driven imports tag entries with the right asset instead of smuggling it into the version string. A typical prompt: "Review my draft changelog entries, rewrite them for customers, and publish them."

Next Steps