LogPulse

Changelogs for coding agents: look up versions, breaking changes and migration notes, and turn any changelog into structured JSON (free, no sign-in).

View on lovable.app

Hosted MCP Server

npx add-mcp 'https://release-ripple-roadmap.lovable.app/mcp'

Installs into Claude Code, Codex, Cursor and more

Documentation

Changelogs coding agents can upgrade from.

Every release you publish becomes a structured feed and an MCP server — versions, breaking changes, migration steps, deprecations. When someone asks their agent “what changed since v1.4, and what do I need to change?”, the answer comes from you, not a guess.

~/acme-dashboard — coding agent logpulse mcp

you › We're on @acme/analytics 1.4. Upgrade us to 2.0.

⏺ compare_versions(changelog: "acme", from: "1.4.0", to: "2.0.0")

⎿ 7 releases · 3 breaking changes · 3 deprecations

Three things need to change before 2.0:

  1. 1acme.track() no longer takes a callback → await acme.track(name, props)
  2. 2Page-number pagination is gone → send?cursor= from next_cursor
  3. 3Funnel step ids are strings now → update the id column type

Also: ACME_API_KEY is deprecated — switch to ACME_PROJECT_TOKEN before 3.0.

Applying 3 changes in 5 files…

SourceAcme's own changelog, not training data

Works with any MCP clientClaude CodeCursorLovableVS CodeWindsurfCodexZedCline

Why it matters

Agents upgrade from memory. Memory is out of date.

Coding agents write code against the version of your library they saw in training. When you ship a breaking change, they don't know — and your users pay for it in broken builds and support tickets.

Without LogPulse

  • Agents guess your API from stale training data
  • Release notes are prose, scattered across GitHub, blogs and docs
  • Migration steps get lost; deprecations surprise people at removal
  • Third-party scrapers paraphrase your notes and get them wrong

With LogPulse

  • Agents read your releases from the source, through MCP or JSON
  • Every release carries a version, breaking changes and deprecations
  • One call answers “what changed between 1.4 and 2.0?” with your migration steps
  • Your users still get a polished widget, hosted changelog and emails

How it works

Publish once. People and agents both get it.

Write a release in the dashboard, let AI draft it from GitHub, or post it from CI. LogPulse turns it into every format your users read.

  1. 01

    Ship and publish

    Write notes in the editor, approve an AI draft made from your merged PRs, or POST from your agent or CI with an API key.
  2. 02

    Add the upgrade details

    Tag the version, list breaking changes with migration steps, and mark deprecations with their replacement and removal version.
  3. 03

    Agents ask, you answer

    Claude Code, Cursor and Lovable query your changelog through MCP or JSON and apply your migration steps — while people read the widget.

Live data, not a mockup

One call. Everything between two versions.

This is the real answer for Acme Analytics, 1.4.0 → 2.0.0: 7 releases, 3 breaking changes and 3 deprecations — ordered so an agent can work through them.

curl "https://release-ripple-roadmap.lovable.app/api/public/v1/changelogs/acme/diff?from=1.4.0&to=2.0.0&format=markdown"

3 breaking changes

  1. v2.0.0 acme.track() no longer accepts a callback @acme/analytics SDK Replace acme.track(name, props, cb) with await acme.track(name, props). Wrap calls in try/catch if you relied on the callback error argument.
  2. v2.0.0 Page-number pagination removed from GET /v1/events REST API Use the next_cursor value from each response as ?cursor= on the next request. The page and per_page parameters now return 400.
  3. v2.0.0 Funnel step ids are now strings REST API, webhooks Store funnel step ids as strings; numeric ids are no longer returned.

3 deprecations

  • v1.5.0 acme.track(event, props, callback) → use await acme.track(event, props) · removed in 2.0.0Callbacks are replaced by promises.
  • v1.6.0 GET /v1/events?page=N → use GET /v1/events?cursor=… · removed in 2.0.0Page-number pagination is slow on large projects.
  • v1.8.0 ACME_API_KEY environment variable → use ACME_PROJECT_TOKEN · removed in 3.0.0

Two-minute setup

Point any agent at one URL.

Agents read any public changelog with no keys. Give yours an API key and it publishes the release note the moment it ships.

  • search_changelogs find a changelog by package or repo name
  • list_releases · get_release versions, notes and upgrade details
  • compare_versions breaking changes and migrations between two versions
  • get_roadmap what's planned, in progress and shipped
  • publish_release · post_roadmap_update with your API key: ship, then announce MCP server docs
claude mcp add --transport http logpulse https://release-ripple-roadmap.lovable.app/mcp

AGENTS.md — publish a release after every ship

## Release notes (LogPulse)

After you ship a user-facing change, publish a release note to our LogPulse changelog "your-product":

- If the LogPulse MCP server is connected (https://release-ripple-roadmap.lovable.app/mcp, with our API key in its Authorization header), call publish_release. Otherwise POST https://release-ripple-roadmap.lovable.app/api/public/v1/releases with header \`Authorization: Bearer $LOGPULSE_API_KEY\`.
- Fields: "title", "version", "category": "new" | "improved" | "fixed", "body" (markdown), "status": "published"
- List breaking changes in "breaking_changes": [{ "summary", "affects", "migration" }] and deprecations in "deprecations": [{ "item", "replacement", "removal_version" }]
- Use "status": "draft" when a human should review it first.
- When a roadmap item ships, call post_roadmap_update (or PATCH https://release-ripple-roadmap.lovable.app/api/public/v1/roadmap/{id}) with { "status": "shipped", "linked_release": "<version>" }.
- Never paste the API key into chat or commit it; it lives in the environment.

Spec: https://release-ripple-roadmap.lovable.app/openapi.json

And for the humans

The same releases, in a widget people actually open

A tiny “What’s new” widget, a hosted changelog and a public roadmap come with every plan. This is the real widget — try it.

Display mode

Trigger

Position

Theme

Accent

Simulated new releases3

acme.example.com/dashboard

AAcme Analytics

Home

Reports

Dashboards

People

Settings

Search…

12,480

+12.1%

3.4%

−0.4%

€48.2k

+12.1%

one line · async · <15kb

<script src="https://release-ripple-roadmap.lovable.app/widget.js" data-workspace="acme" data-mode="popover" data-position="bottom-right" data-theme="light" data-accent="#4f6bff" async></script>

Free for open source

Open source is free. Companies pay.

Public repositories with an open-source license get every paid feature at no cost. Link your changelog from your README, verify in one click, and your users' agents can upgrade your library safely. The small “⚡ Powered by LogPulse” link stays on — that's how it stays free.

How it works

  1. 01

    Link it

    Add your LogPulse changelog link to the README.
  2. 02

    Verify

    We check the repo is public, licensed and not a fork.
  3. 03

    Ship

    Unlimited releases, AI drafts and emails — free for a year, renewable.

Pricing

Free to read. Free for open source. Simple for companies.

Pro is €12/month — or €99/year and save 31%.

Free

€0 forever

  • Up to 10 published releases
  • JSON feed, MCP server & API
  • Widget, hosted changelog & roadmap
  • ⚡ Powered by LogPulse badge

Start free

Open source

€0 for public repos

  • Unlimited releases & subscribers
  • AI drafts from GitHub
  • Email blast on every release
  • Up to 5 team members

Apply in one click

Pro

For companies

€12 per month

  • Everything in Open source
  • For commercial products
  • Remove LogPulse branding
  • Custom domain on request

See Pro details

Guides

Write release notes people can upgrade from

Fact-checked guides with copy-paste templates: open-source libraries, npm and PyPI packages, notes from commits and breaking changes.

All 14 release notes guides

Open-source libraries and packages

How to write release notes for open-source libraries

A copy-paste Markdown template, real examples from Django, Python and Node.js, and a checklist for release notes your library's users can upgrade from.

Read the guide Open-source libraries and packages

Release notes templates in Markdown

Five Markdown release notes templates for libraries and developer tools: a CHANGELOG.md entry, a GitHub release, a major version, a security fix and a monorepo.

Read the guide Open-source libraries and packages

How to write release notes from commits (Conventional Commits)

Turn commit messages into release notes: the Conventional Commits format, how types map to changelog sections and versions, tools that automate it, and what to edit.

Read the guide

Also:Keep a Changelog vs GitHub Releases Changelogs for npm packages Changelogs for PyPI packages Announcing breaking changes