← Use cases

Release notes your users can actually follow

A CHANGELOG.md is for contributors. Changelore gives the same work a readable, followable home for the people who just use your project.

Maintainers already write release notes — in tags, in CHANGELOG.md, in release descriptions. But that lives in the repo, formatted for people who read diffs. Users who just installed your package have no good way to follow what changed, and no way to subscribe.

Bring your CHANGELOG.md with you

Import your existing history — your agent maps it over MCP, keeping the original dates and never emailing anyone about a five-year-old release.

Release notes drafted from commits

Between releases, let your agent group the merges into a readable entry instead of a raw commit dump.

RSS for people who do not watch the repo

A public page plus an RSS feed means users can follow releases without a GitHub account or notification fatigue.

Free for one project

One project, the hosted page, RSS, API and MCP access are free — enough for most projects to run their changelog permanently.

import an existing CHANGELOG.md
> import my CHANGELOG.md into changelore

Agent → parses keepachangelog, maps each release,
        preserves dates, imports silently:

  found 34 releases → created 34 (no emails sent)

New releases from then on:
> draft release notes for v3.2 from commits

Questions

Will importing my old releases spam subscribers?
No. Historical imports are silent by design — no subscriber emails and no webhooks fire for backfilled entries.
Does it replace GitHub Releases?
It complements them. Keep tagging releases as usual; Changelore gives non-contributors a readable page and an RSS feed to follow.

Changelore is launching soon

The changelog written from your code. Join the waitlist for early access.

Join the waitlist