ForHosting KIT · Outils pour développeurs

Incrémentez une version sémantique par major, minor ou patch

Obtenez le prochain numéro de version sans erreur : un incrément minor fait passer 2.7.4 à 2.8.0, avec le patch remis à zéro, et tout suffixe de préversion ou de build disparaît, car une nouvelle série commence. Gratuit dans votre navigateur.

Gratuit
Fonctionne dans votre navigateur
Sans inscription
Vos données restent sur votre appareil

Lancer gratuitement Voir l’API

Utilisez-le depuis WebAPIE-mailTelegramApp bientôt

Exemple résolu

Si vous saisissez

Version: 2.7.4
Type d'incrément: Minor

Vous obtenez

Version d'origine: 2.7.4
Version incrémentée: 2.8.0

L’outil d’incrémentation sémantique calcule le prochain numéro de publication à partir d’une chaîne Semantic Versioning 2.0.0 valide et du type choisi. Sélectionnez major, minor ou patch : le composant demandé augmente et tous les composants inférieurs reviennent à zéro. Les libellés de préversion et les métadonnées de build disparaissent, car le résultat représente une nouvelle ligne de publication normale. La validation stricte détecte les versions mal formées et les types inconnus avant leur arrivée dans vos scripts, publications de paquets, journaux de modifications ou pipelines de livraison continue.

Choisissez le changement de publication à communiquer

Semantic Versioning attribue un sens distinct à chacun des trois nombres principaux ; le bon incrément dépend donc de la nature du changement publié. Le calculateur augmente major et remet minor et patch à zéro : 4.8.6 devient ainsi 5.0.0. Choisissez minor pour une fonctionnalité ajoutée de façon rétrocompatible.

Minor augmente alors que patch revient à zéro, et 4.8.6 devient 4.9.0. Choisissez patch pour des corrections rétrocompatibles ; la même entrée produit 4.8.7. L’opération reste volontairement mécanique : elle n’analyse ni le code source, ni les commits, ni le journal des modifications et ne peut pas décider si une modification est incompatible.

Cette qualification relève de votre politique de publication. Une fois le type sélectionné, le calcul est cohérent et reproductible. Cette séparation convient aux systèmes dans lesquels une personne, une étiquette de pull request ou un analyseur de commits choisit la catégorie et attend un calcul final fiable.

Maîtrisez la validation stricte et la suppression des suffixes

La version doit respecter exactement Semantic Versioning 2.0.0 et contenir les composants major, minor et patch. 1.2.3, 2.0.0-rc.1 et 3.4.5+linux.x64 sont des exemples valides. Les formes permissives telles que v1.2.3, 1.2 ou les nombres principaux comportant des zéros initiaux sont refusées au lieu d’être corrigées silencieusement.

Les identifiants de préversion et les métadonnées de build sont validés dans l’entrée, mais aucun suffixe ne subsiste dans le résultat incrémenté. Un incrément ouvre un nouveau numéro principal : un patch de 2.1.0-beta.3 donne 2.1.1, tandis qu’un minor donne 2.2.0. Cette règle évite de reporter un ancien libellé de version candidate sur une nouvelle ligne.

Le type constitue également un choix fini et strict : major, minor ou patch en minuscules. Cette rigueur est précieuse en automatisation, car les fautes, raccourcis de gestionnaires de paquets et versions incomplètes s’arrêtent clairement avant la création d’une étiquette erronée difficile à retirer.

Automatisez vos publications avec un calcul déterministe

Le calculateur constitue une petite étape déterministe au sein d’un processus de publication plus vaste. Le traitement n’utilise ni réseau, ni horloge, ni valeur aléatoire, ni modèle externe, ni état conservé : des entrées identiques produisent toujours des sorties identiques. Les composants numériques sont incrémentés comme des chaînes de chiffres décimaux et non comme des nombres JavaScript.

Le résultat demeure donc exact même au-delà de la plage des entiers sûrs, sans surprise d’arrondi. Utilisez l’exécuteur du navigateur pour une vérification ponctuelle.

Cas d’usage

Préparez la publication d’un paquet

Calculez la prochaine version du manifeste après l’approbation d’une publication major, minor ou patch.

Pilotez une livraison continue

Transformez une catégorie issue d’étiquettes ou de commits en version déterministe pour les étapes suivantes.

Validez une version proposée

Comparez l’incrément calculé à la version d’une demande avant de créer des étiquettes ou publier des artefacts.

Questions fréquentes

Que fait chaque type d’incrément ?

Major augmente major et remet minor et patch à zéro. Minor augmente minor et remet patch à zéro. Patch augmente uniquement patch.

Les libellés de préversion sont-ils conservés ?

Non. Un suffixe valide est accepté en entrée, puis retiré de la nouvelle version principale.

Les métadonnées de build influencent-elles le résultat ?

Non. Elles sont acceptées si elles sont valides, puis supprimées lors du calcul.

Pouvez-vous ajouter un v initial ou omettre patch ?

Non. L’entrée doit être une chaîne Semantic Versioning 2.0.0 stricte avec ses trois composants principaux.

Décide-t-il quel incrément mon changement exige ?

Non. Il ne lit ni le code, ni les commits, ni les notes de version, et ne peut pas savoir si un changement casse la compatibilité. Vous ou vos règles de publication choisissez major, minor ou patch ; il fait ensuite le calcul toujours de la même façon.

Outils associés

Pour les développeurs — accès API

Tout sur cette page est disponible par programmation. Cette section s'adresse aux équipes qui veulent l'intégrer à leurs systèmes ; les autres peuvent simplement utiliser l'outil ci-dessus.

Endpoint

POSThttps://api.kit.forhosting.com/dev2/semver-bump

Authentification par jeton Bearer : un seul POST met la tâche en file d’attente, et le résultat vous parvient par webhook ou lien signé.

Appeler depuis votre 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)

Exemple de requête

{
  "version": "2.7.4",
  "bump_type": "minor"
}

Exemple de réponse

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

L’API est asynchrone : chaque appel renvoie un task_id immédiatement, puis vous interrogez l’état à raison d’une requête par seconde.

Tarifs

par requête$0.002

Le prix est publié, sans tokens ni crédits. Une tâche qui échoue n’est pas facturée.

Erreurs

HTTP	Code	Signification
`401`	`unauthorized`	Clé API absente ou invalide : vérifiez l’en-tête Authorization.
`402`	`insufficient_balance`	Solde insuffisant : rechargez votre compte pour lancer cette tâche.
`404`	`unknown_type`	Type de tâche inconnu : vérifiez le champ type de votre requête.
`429`	`rate_limited`	Trop de requêtes : ralentissez la cadence, puis réessayez.

Notes techniques

Choisissez le changement de publication à communiquer

Choisissez major lorsque la nouvelle version introduit des modifications incompatibles de l’API publique.

Maîtrisez la validation stricte et la suppression des suffixes

Tout autre nom renvoie invalid_input.

Automatisez vos publications avec un calcul déterministe

Envoyez la version actuelle et le type approuvé, puis utilisez bumped_version pour modifier un manifeste, créer une branche, nommer un artefact ou proposer une étiquette de dépôt. La réponse reprend également original_version et bump_type, ce qui facilite l’audit des journaux et écrans d’approbation sans reconstituer la requête. Lorsqu’un service de build, une CLI ou l’intégration continue doit automatiser ce calcul, appelez l’API pour $0.002 par élément et traitez invalid_input comme une anomalie des données de publication à corriger avant diffusion.

Questions techniques

Que se passe-t-il pour un type inconnu ?

La requête renvoie invalid_input. Seuls major, minor et patch sont reconnus.

Quel est le prix de l’API ?

Le prix de l’API est de $0.002 par élément ; l’exécuteur du navigateur permet les vérifications interactives.

Consulter la documentation complète du KIT →

Lancer gratuitement

Exemple résolu

Choisissez le changement de publication à communiquer

Maîtrisez la validation stricte et la suppression des suffixes

Automatisez vos publications avec un calcul déterministe

Cas d’usage

Préparez la publication d’un paquet

Pilotez une livraison continue

Validez une version proposée

Questions fréquentes

Outils associés

Pour les développeurs — accès API

Endpoint

Appeler depuis votre stack

Exemple de requête

Exemple de réponse

Tarifs

Erreurs

Notes techniques

Choisissez le changement de publication à communiquer

Maîtrisez la validation stricte et la suppression des suffixes

Automatisez vos publications avec un calcul déterministe

Questions techniques

merci