ForHosting KIT · Text & KI

Changelog schreiben

Das Werkzeug wandelt eine Liste von Commit-Nachrichten oder Stichpunkten in einen gegliederten Changelog um – sortiert nach neuen Funktionen, Fehlerbehebungen und Breaking Changes. Es richtet sich an Entwicklerteams, die vor jedem Release Release Notes für Kundinnen, Kunden oder die eigene Dokumentation brauchen.

● Stabilpro Anfrage + pro Release$0.003

Ausführen — $0.003 + $0.0135/Release API ansehen

Nutzen Sie es über WebAPIE-MailApp baldTelegram bald

Online ausführen

Führen Sie dies mit Ihrem Konto auf unseren Servern aus. Kostenlose Tools laufen in Ihrem Browser; dieses wird zum oben genannten Preis von Ihrem KIT-Guthaben abgebucht.

Aus rohen Commits wird eine Gliederung

Eingefügte Commit-Nachrichten oder Stichpunkte werden automatisch nach neuen Funktionen, Verbesserungen, Fehlerbehebungen und einschneidenden Änderungen sortiert. Technische Formulierungen aus dem Commit-Verlauf – etwa „fix: null pointer in parser“ – werden dabei in einen für Leserinnen und Leser verständlichen Satz übersetzt, ohne die technische Genauigkeit der ursprünglichen Angabe zu verlieren. Bei mehrdeutigen oder sehr knappen Commit-Nachrichten bleibt die Zuordnung eine Einschätzung; eine kurze eigene Ergänzung in der Eingabe verbessert das Ergebnis in solchen Fällen spürbar.

Zwei Zielgruppen, zwei Versionen

Ein interner Changelog für das Entwicklerteam darf technische Begriffe wie „Endpunkt“ oder „Migration“ enthalten; ein öffentlicher Changelog für Kundinnen und Kunden braucht dieselbe Information in allgemeinverständlicher Sprache, oft mit dem Nutzen für die Anwenderin im Vordergrund statt der technischen Umsetzung. Die Angabe der Zielgruppe in der Eingabe steuert diesen Unterschied direkt. Wer unsicher ist, welche Formulierung für die eigene Kundschaft passt, lässt beide Fassungen nebeneinander erstellen und wählt die passendere für die jeweilige Veröffentlichung aus.

Breaking Changes deutlich kennzeichnen

Änderungen, die bestehende Integrationen brechen können, werden als eigener Abschnitt hervorgehoben, nicht zwischen kleineren Verbesserungen versteckt. Das entspricht der Erwartung von Entwicklerteams, die einen Changelog vor allem daraufhin durchsuchen, ob ein Update die eigene Anbindung gefährdet, bevor sie überhaupt die neuen Funktionen lesen. Für ein Team, das monatlich mehrere Releases veröffentlicht, ist dieser eigene Abschnitt oft der erste Blick auf einen neuen Changelog, noch vor den übrigen Neuerungen.

Einbindung in den Release-Ablauf

Über die API lässt sich die Erstellung an die eigene Build-Pipeline anbinden, sodass bei jedem Release automatisch ein Entwurf des Changelogs entsteht. Das Browser-Widget auf dieser Seite eignet sich für einzelne Releases oder für Teams, die den Ablauf noch nicht automatisiert haben. So bleibt der Changelog auch bei sehr häufigen Releases aktuell, ohne dass jemand im Team die Zusammenstellung jedes Mal von Hand nachträgt.

Anwendungsfälle

Das monatliche Software-Update

Die Schneider IT-Systeme GmbH & Co. KG veröffentlicht monatlich ein Update ihrer Verwaltungssoftware. Der Entwickler fügt die Commit-Liste des letzten Monats ein und erhält einen gegliederten Entwurf, den das Team vor der Veröffentlichung noch um Screenshots ergänzt.

Zwei Fassungen für zwei Zielgruppen

Ein kleines Softwareteam braucht für dasselbe Release einen technischen Changelog fürs interne Wiki und eine allgemeinverständliche Fassung für die Kundinnen und Kunden. Beide Fassungen entstehen aus derselben Commit-Liste mit unterschiedlicher Zielgruppenangabe.

Der Breaking Change vor dem Wochenende

Lukas Fischer will vor einem größeren Versionssprung sicherstellen, dass alle einschneidenden Änderungen sichtbar hervorgehoben sind. Der erzeugte Changelog trennt Breaking Changes klar von kleineren Verbesserungen, bevor er ihn an bestehende Integrationspartner verschickt.

Häufige Fragen

Erkennt das Werkzeug Breaking Changes automatisch?

Es ordnet als solche gekennzeichnete oder erkennbar einschneidende Änderungen einem eigenen Abschnitt zu. Eine abschließende technische Prüfung durch das Entwicklerteam ersetzt das nicht.

Kann ich eine technische und eine kundenfreundliche Fassung erstellen?

Ja, über die Angabe der Zielgruppe in der Eingabe – intern oder öffentlich – entstehen unterschiedlich formulierte Fassungen aus derselben Commit-Liste.

Was passiert mit den eingereichten Commit-Nachrichten?

Sie werden nur zur Erstellung dieses einen Changelogs verarbeitet und danach nicht dauerhaft gespeichert.

Was kostet ein Changelog?

$0.003 pro Anfrage plus $0.0135 pro erzeugtem Release-Eintrag.

Lässt sich das in die Build-Pipeline einbinden?

Ja, über die API lässt sich die Erstellung bei jedem Release automatisch anstoßen, statt die Commit-Liste jedes Mal manuell einzufügen.

Muss ich Git-Commits verwenden, oder reichen Stichpunkte?

Beides funktioniert. Rohe Commit-Nachrichten werden ebenso verarbeitet wie eine einfache Liste von Stichpunkten zu den Änderungen.

Für Entwickler — API-Zugang

Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.

Endpunkt

POSThttps://api.kit.forhosting.com/text/changelog

Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.

Aufruf aus Ihrem Stack

curl -X POST https://api.kit.forhosting.com/text/changelog \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d &#39;{"input":"…"}'

const res = await fetch("https://api.kit.forhosting.com/text/changelog", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "input": "…"
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/text/changelog",
    headers={"Authorization": f"Bearer {os.environ[&#39;KIT_KEY']}"},
    json={
    "input": "…"
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/text/changelog", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => &#39;{"input":"…"}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"input":"…"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/text/changelog", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Beispiel-Anfrage

{
  "input": "…"
}

Beispiel-Antwort

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "text.changelog",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.

Preis

pro Anfrage$0.003

pro Release$0.0135

Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.

Limits

max_tokens 20000

Fehler

HTTP	Code	Bedeutung
`401`	`unauthorized`	Der API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer).
`402`	`insufficient_balance`	Ihr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht.
`404`	`unknown_type`	Unbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog.
`429`	`rate_limited`	Zu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt.
`422`	`task_failed`	Die Aufgabe ist fehlgeschlagen und wird nicht berechnet.

Vollständige KIT-Dokumentation lesen →