Semantische Version um Major, Minor oder Patch erhöhen
Erhalten Sie die nächste Versionsnummer ohne Flüchtigkeitsfehler: Eine minor-Erhöhung macht aus 2.7.4 die 2.8.0, der Patch-Teil fällt auf null, und Vorabversions- oder Build-Zusätze entfallen, weil eine neue Release-Linie beginnt. Kostenlos in Ihrem Browser.
- Kostenlos
- Läuft in Ihrem Browser
- Ohne Anmeldung
- Ihre Daten bleiben auf Ihrem Gerät
Im Browser ausführen – kostenlos
Rechenbeispiel
- Version
- 2.7.4
- Erhöhungsart
- Minor
- Ursprüngliche Version
- 2.7.4
- Erhöhte Version
- 2.8.0
Das Werkzeug zur Erhöhung semantischer Versionen berechnet aus einer gültigen Semantic-Versioning-2.0.0-Zeichenfolge und der gewählten Änderungsart die nächste Release-Nummer. Wählen Sie major, minor oder patch: Die gewünschte Komponente wird erhöht, alle kleineren Komponenten werden auf null gesetzt. Vorabversionskennzeichen und Build-Metadaten entfallen, weil das Ergebnis eine neue reguläre Release-Linie darstellt. Die strikte Prüfung erkennt fehlerhafte Versionen und unbekannte Änderungsarten, bevor diese in Release-Skripte, Paketveröffentlichungen, Änderungsprotokolle oder Continuous-Delivery-Pipelines gelangen.
Wählen Sie die mitzuteilende Release-Änderung
Semantic Versioning weist jeder der drei Kernzahlen eine eigene Bedeutung zu. Deshalb beginnt die richtige Erhöhung mit der Art der veröffentlichten Änderung. Der Rechner erhöht major und setzt minor sowie patch auf null; aus 4.8.6 wird 5.0.0.
Wählen Sie minor, wenn Funktionen rückwärtskompatibel ergänzt werden. Dann wird minor erhöht und patch zurückgesetzt, sodass 4.8.6 zu 4.9.0 wird. Wählen Sie patch für rückwärtskompatible Fehlerbehebungen; dieselbe Eingabe ergibt 4.8.7.
Der Vorgang ist bewusst mechanisch: Er untersucht weder Quellcode noch Commits oder Änderungsprotokolle und kann nicht entscheiden, ob eine Änderung inkompatibel ist. Diese Einstufung bleibt Bestandteil Ihrer Release-Richtlinie. Nach der Auswahl ist die Berechnung jedoch einheitlich und wiederholbar.
Das eignet sich für Systeme, in denen eine Person, ein Pull-Request-Label oder eine Commit-Analyse die Kategorie festlegt und anschließend eine verlässliche Berechnung benötigt.
Verstehen Sie die strikte Prüfung und Entfernung von Zusätzen
Die Version muss Semantic Versioning 2.0.0 genau entsprechen und major, minor sowie patch enthalten. Gültige Beispiele sind 1.2.3, 2.0.0-rc.1 und 3.4.5+linux.x64. Lockere Formen wie v1.2.3, 1.2 oder Kernzahlen mit führenden Nullen werden abgelehnt und nicht stillschweigend berichtigt.
Vorabversionskennzeichen und Build-Metadaten werden als Teil der Eingabe validiert, bleiben aber nicht im erhöhten Ergebnis erhalten. Eine Erhöhung eröffnet eine neue Kernversion: Ein patch für 2.1.0-beta.3 ergibt 2.1.1, ein minor ergibt 2.2.0. So wird kein altes Release-Candidate-Kennzeichen auf eine neue Linie übertragen.
Auch die Änderungsart ist eine strikte endliche Auswahl: major, minor oder patch in Kleinbuchstaben.
Nutzen Sie deterministische Versionsarithmetik in der Automation
Der Rechner dient als kleiner deterministischer Schritt innerhalb eines größeren Release-Ablaufs. Senden Sie die aktuelle Version und die genehmigte Änderungsart. Die Verarbeitung verwendet weder Netzwerk noch Uhrzeit, Zufallswerte, externe Modelle oder gespeicherten Zustand; gleiche Eingaben liefern stets gleiche Ausgaben.
Numerische Komponenten werden als dezimale Ziffernfolgen und nicht als JavaScript-Zahlen erhöht. Dadurch bleibt die Berechnung selbst bei gültigen Komponenten oberhalb des sicheren Ganzzahlbereichs exakt und verursacht keine Rundungsfehler. Verwenden Sie den Browser-Ausführer für gelegentliche Prüfungen.
Anwendungsfälle
Bereiten Sie ein Paket-Release vor
Berechnen Sie nach der Freigabe eines major-, minor- oder patch-Release die nächste Manifestversion.
Steuern Sie eine Continuous-Delivery-Pipeline
Wandeln Sie eine Kategorie aus Labels oder Commits in eine deterministische Version für Folgeschritte um.
Prüfen Sie eine vorgeschlagene Version
Vergleichen Sie die berechnete Erhöhung vor Tag-Erstellung oder Veröffentlichung mit dem Vorschlag.
Häufige Fragen
Was bewirken die einzelnen Änderungsarten?
Major erhöht major und setzt minor und patch zurück. Minor erhöht minor und setzt patch zurück. Patch erhöht nur patch.
Bleiben Vorabversionskennzeichen erhalten?
Nein. Ein gültiger Zusatz wird in der Eingabe akzeptiert, aber aus der neuen Kernversion entfernt.
Beeinflussen Build-Metadaten das Ergebnis?
Nein. Gültige Metadaten werden angenommen und bei der Berechnung der neuen Version entfernt.
Dürfen Sie ein v voranstellen oder patch auslassen?
Nein. Die Eingabe muss eine strikte Semantic-Versioning-2.0.0-Zeichenfolge mit allen drei Kernteilen sein.
Entscheidet das Werkzeug, welche Erhöhung meine Änderung braucht?
Nein. Es liest weder Code noch Commits noch Versionshinweise und kann nicht erkennen, ob eine Änderung inkompatibel ist. Sie oder Ihre Release-Regeln wählen major, minor oder patch; danach wird immer gleich gerechnet.
Verwandte Tools
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
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/dev2/semver-bump \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"version":"2.7.4","bump_type":"minor"}'const res = await fetch("https://api.kit.forhosting.com/dev2/semver-bump", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"version": "2.7.4",
"bump_type": "minor"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev2/semver-bump",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"version": "2.7.4",
"bump_type": "minor"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev2/semver-bump", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"version":"2.7.4","bump_type":"minor"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"version":"2.7.4","bump_type":"minor"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev2/semver-bump", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Beispiel-Anfrage
{
"version": "2.7.4",
"bump_type": "minor"
}Beispiel-Antwort
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev2.semver_bump",
"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
Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.
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. |
Technische Hinweise
Wählen Sie die mitzuteilende Release-Änderung
Wählen Sie major, wenn das neue Release inkompatible Änderungen an der öffentlichen API enthält.
Verstehen Sie die strikte Prüfung und Entfernung von Zusätzen
Jeder andere Name führt zu invalid_input. Diese Strenge ist besonders in automatisierten Abläufen wertvoll, weil Tippfehler, Kurzformen von Paketmanagern und unvollständige Versionen sichtbar gestoppt werden, bevor ein falsches Tag entsteht, das nach der Veröffentlichung nur schwer zurückgenommen werden kann.
Nutzen Sie deterministische Versionsarithmetik in der Automation
Verwenden Sie danach bumped_version für ein Manifest-Update, einen Release-Branch, eine Artefaktbezeichnung oder ein vorgeschlagenes Repository-Tag. Die Antwort wiederholt außerdem original_version und bump_type, sodass Protokolle und Freigabeansichten ohne Rekonstruktion der Anfrage leichter geprüft werden können. Wenn ein Build-Dienst, eine CLI oder Continuous Integration die Berechnung automatisiert benötigt, rufen Sie die API für $0.002 pro Element auf und behandeln Sie invalid_input als zu behebenden Fehler in den Release-Daten.
Technische Fragen
Was geschieht bei einer unbekannten Änderungsart?
Die Anfrage liefert invalid_input. Nur major, minor und patch werden erkannt.
Was kostet die API?
Der API-Preis beträgt $0.002 pro Element; der Browser-Ausführer steht für interaktive Prüfungen bereit.