Incrementi una versione semantica: major, minor o patch
Ottenga il prossimo numero di versione senza sviste: un incremento minor trasforma 2.7.4 in 2.8.0, con il patch azzerato, e ogni suffisso di pre-release o di build sparisce perché inizia una nuova linea di versioni. Gratis nel suo browser.
- Gratis
- Funziona nel suo browser
- Senza registrazione
- I suoi dati restano sul dispositivo
Esegui gratis nel browser
Esempio risolto
- Versione
- 2.7.4
- Tipo di incremento
- Minor
- Versione originale
- 2.7.4
- Versione incrementata
- 2.8.0
Lo strumento di incremento semantico calcola il prossimo numero di rilascio partendo da una stringa Semantic Versioning 2.0.0 valida e dal tipo scelto. Selezioni major, minor o patch: il componente richiesto aumenta e tutti quelli inferiori tornano a zero. Le etichette di pre-release e i metadati di build vengono rimossi, perché il risultato rappresenta una nuova linea di rilascio normale. La convalida rigorosa intercetta versioni malformate e tipi non riconosciuti prima che entrino in script, pubblicazione di pacchetti, changelog o pipeline di distribuzione continua.
Scelga il cambiamento di rilascio che intende comunicare
Semantic Versioning assegna un significato distinto a ciascuno dei tre numeri principali, quindi l’incremento corretto dipende dal tipo di modifica pubblicata. Il calcolatore incrementa major e azzera minor e patch, trasformando 4.8.6 in 5.0.0. Scelga minor quando viene aggiunta una funzionalità retrocompatibile.
In tal caso minor aumenta e patch torna a zero, così 4.8.6 diventa 4.9.0. Scelga patch per correzioni retrocompatibili: con lo stesso input otterrà 4.8.7. L’operazione è volutamente meccanica: non esamina codice sorgente, commit o changelog e non può stabilire se una modifica interrompa la compatibilità.
Questa classificazione rimane parte della Sua politica di rilascio. Una volta selezionato il tipo, tuttavia, l’aritmetica è coerente e ripetibile. La separazione è utile quando una persona, un’etichetta di pull request o un analizzatore di commit determina la categoria e necessita di un calcolo finale affidabile.
Comprenda la convalida rigorosa e la rimozione dei suffissi
La versione deve rispettare esattamente Semantic Versioning 2.0.0 e includere major, minor e patch. Esempi validi sono 1.2.3, 2.0.0-rc.1 e 3.4.5+linux.x64. Forme permissive come v1.2.3, 1.2 o numeri principali con zeri iniziali vengono respinte anziché corrette senza avviso.
Gli identificatori di pre-release e i metadati di build sono convalidati nell’input, ma nessun suffisso resta nel risultato incrementato. Un incremento apre un nuovo numero principale: applicare patch a 2.1.0-beta.3 produce 2.1.1, mentre minor produce 2.2.0. Questa scelta evita di trascinare una vecchia etichetta su una nuova linea.
Anche il tipo è una scelta finita e rigorosa: major, minor o patch in minuscolo. Tale rigore è prezioso nell’automazione, perché errori di battitura, scorciatoie dei gestori di pacchetti e versioni incomplete vengono fermati chiaramente prima di creare un tag errato e difficile da ritirare dopo la pubblicazione.
Usi un calcolo deterministico nell’automazione dei rilasci
Il calcolatore è una piccola fase deterministica inseribile in un processo di rilascio più ampio. L’elaborazione non usa rete, orologio, valori casuali, modelli esterni o stato memorizzato: input identici producono sempre output identici. I componenti numerici vengono incrementati come stringhe di cifre decimali, non come numeri JavaScript.
Il comportamento resta esatto anche per componenti validi oltre l’intervallo degli interi sicuri, evitando arrotondamenti inattesi. Usi l’esecutore nel browser per controlli occasionali.
Casi d'uso
Prepari il rilascio di un pacchetto
Calcoli la prossima versione del manifesto dopo l’approvazione di un rilascio major, minor o patch.
Gestisca una pipeline di distribuzione continua
Trasformi una categoria ricavata da etichette o commit in una versione deterministica per le fasi successive.
Convalidi una versione proposta
Confronti l’incremento calcolato con la versione di una richiesta prima di creare tag o pubblicare artefatti.
Domande frequenti
Che cosa fa ciascun tipo di incremento?
Major incrementa major e azzera minor e patch. Minor incrementa minor e azzera patch. Patch incrementa soltanto patch.
Le etichette di pre-release vengono mantenute?
No. Un suffisso valido è accettato nell’input, ma rimosso dalla nuova versione principale.
I metadati di build influiscono sul risultato?
No. Se validi vengono accettati, poi rimossi durante il calcolo della nuova versione.
Può usare una v iniziale oppure omettere patch?
No. L’input deve essere una stringa Semantic Versioning 2.0.0 rigorosa con tutti e tre i componenti.
Decide lo strumento quale incremento serve alla mia modifica?
No. Non legge codice, commit né note di rilascio e non può sapere se una modifica rompe la compatibilità. Lei o le sue regole di rilascio scelgono major, minor o patch; poi il calcolo viene fatto sempre allo stesso modo.
Strumenti correlati
Per sviluppatori — accesso via API
Tutto quello che vedi in questa pagina è disponibile anche via API. Questa sezione è per i team che vogliono integrarlo nei propri sistemi; chi non ne ha bisogno può semplicemente usare lo strumento qui sopra.
Endpoint
Autenticazione con Bearer token: un POST mette in coda l'attività e il risultato arriva via webhook o link firmato.
Chiamala dal tuo 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)Esempio di richiesta
{
"version": "2.7.4",
"bump_type": "minor"
}Esempio di risposta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev2.semver_bump",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L'API è asincrona: ricevi subito un task_id e puoi fare polling fino a 1 richiesta al secondo.
Prezzi
Prezzo pubblicato, senza token né crediti. Se l'attività fallisce, non paghi.
Errori
| HTTP | Codice | Significato |
|---|---|---|
401 | unauthorized | Chiave API mancante o non valida: controlla l'header Authorization. |
402 | insufficient_balance | Credito esaurito: ricarica per continuare a eseguire attività. |
404 | unknown_type | Tipo di attività sconosciuto: controlla il campo type della richiesta. |
429 | rate_limited | Troppe richieste in poco tempo: rallenta e riprova tra qualche secondo. |
Note tecniche
Scelga il cambiamento di rilascio che intende comunicare
Scelga major quando la nuova versione introduce cambiamenti incompatibili nell’API pubblica.
Comprenda la convalida rigorosa e la rimozione dei suffissi
Qualsiasi altro nome restituisce invalid_input.
Usi un calcolo deterministico nell’automazione dei rilasci
Invii la versione corrente e il tipo approvato, quindi usi bumped_version per aggiornare un manifesto, creare un branch, denominare un artefatto o proporre un tag. La risposta ripete anche original_version e bump_type, facilitando la verifica di log e schermate di approvazione senza ricostruire la richiesta. Quando un servizio di build, una CLI o l’integrazione continua richiedono lo stesso calcolo automatico, chiami l’API a $0.002 per elemento e consideri invalid_input un problema nei dati del rilascio da correggere prima della pubblicazione.
Domande tecniche
Che cosa accade con un tipo sconosciuto?
La richiesta restituisce invalid_input. Sono riconosciuti soltanto major, minor e patch.
Quanto costa l’API?
Il prezzo dell’API è $0.002 per elemento; l’esecutore nel browser consente controlli interattivi.