Für GitHub-Repos und MCP-Clients

Deine Nutzer lesen keine Commit-Messages.

Sie wollen wissen, was neu ist und was behoben wurde. release-log lässt deinen MCP-Client die Commits in Release Notes übersetzen. Du liest gegen und veröffentlichst, ohne selbst eine Datei im Repo anzufassen.

Das Problem

Die Commit-Historie ist korrekt, aber deine Nutzer verstehen sie nicht.

Release Notes schreibt keiner gern

Nach dem Release hängt der Kopf schon am nächsten Ticket. Die Notes entstehen spät, knapp oder gar nicht.

Die CHANGELOG.md hinkt immer hinterher

Eigentlich müsste jeder Pull Request sie mitändern. Meistens denkt erst beim Release jemand daran, und dann fehlt die Hälfte.

Commit-Messages sind für Entwickler

Sie beschreiben, was im Code passiert ist. Deine Nutzer wollen wissen, was sich für sie ändert.

Git-Log seit v0.2.0
  • feat:suggest the app's repositories in "Neues Log" and adopt an existing one
  • feat:replace the installation badge with actionable alerts on the log page
  • feat:ask before leaving the release editor in a dialog, not window.confirm
  • style:widen the editor gutter and fit the block settings menu
  • chore:ignore SQLite WAL side files
v0.3.0Release NotesBestehende Repositories übernehmenNeu
  • Beim Anlegen eines Logs schlägt release-log deine Repositories vor. Liegt dort schon ein Log, übernimmst du es.
  • Fehlt die GitHub App, sagt dir die Log-Seite, was zu tun ist.
  • Verlässt du den Editor mit ungespeicherten Änderungen, fragt er vorher nach.

Die beiden Commits zu style und chore hat der Agent weggelassen, weil sich für Nutzer dadurch nichts ändert.

Funktionen

Was release-log dir abnimmt

Im Repo, ohne dass du es pflegst

Das Log liegt als JSON in einem eigenen GitHub-Repository. release-log schreibt die Dateien, du öffnest sie nie von Hand. Änderst du doch mal etwas direkt auf GitHub, übernimmt die Seite den neuen Stand.

MCP-Server mit OAuth

Dein MCP-Client meldet sich per OAuth an und schreibt Releases mit write_release. Bilder lädt er mit add_mediahoch.

Gegenlesen im Editor

Du änderst Überschrift, Text, Bild und jeden einzelnen Eintrag. Hat inzwischen jemand anderes gespeichert, sagt dir der Editor das, statt dessen Stand zu überschreiben.

Öffentliche Seite und JSON

Unter /l/<id> steht das Changelog als Zeitstrahl, deine eigene App holt dieselben Releases als JSON. Ein privates Log sehen nur Leute mit Schreibrecht auf das Repository.

So funktioniert’s

Vom Commit zur veröffentlichten Seite

  1. 01

    Repository verbinden

    Lege im Dashboard ein neues Log an. Liegt in einem Repository schon eins, übernimmst du es.

  2. 02

    Release schreiben lassen

    Bitte deinen MCP-Client, die Commits seit dem letzten Release zusammenzufassen. Du kannst auch selbst im Editor schreiben.

  3. 03

    Veröffentlichen

    Danach steht das Release auf der Seite und im Feed. Vorher sehen den Entwurf nur Leute mit Schreibrecht.

FAQ

Häufige Fragen

Brauche ich ein GitHub-Konto?

Ja. Anmeldung und Rechte laufen über GitHub, und die GitHub App braucht Zugriff auf das Repository deines Logs.

Welche MCP-Clients funktionieren?

Jeder Client, der MCP mit OAuth unterstützt. Beim ersten Verbinden registriert er sich selbst, und du bestätigst den Zugriff einmal im Browser.

Kann ich Releases vor der Veröffentlichung prüfen?

Ja. Jedes Release beginnt als Entwurf und ist nur für Konten mit Schreibrecht auf das Repository sichtbar.

Kann ich das Changelog in meine App einbauen?

Ja, über den JSON-Feed: /l/<id>/versions, /l/<id>/releases und /l/<id>/releases/<version>.