Conventional Commits et versionnage sémantique
feat, fix, BREAKING CHANGE et MAJEUR.MINEUR.CORRECTIF : deux conventions qui, combinées, automatisent le changelog et le numéro de version.
Conventional Commits : la structure
<type>(<portée optionnelle>): <description> [corps optionnel] [pied optionnel, ex. BREAKING CHANGE: ...]
feat(panier): ajouter la suppression d'un article fix(auth): corriger l'expiration prématurée du token docs: mettre à jour le README d'installation
Types courants
| Type | Usage |
|---|---|
feat |
Nouvelle fonctionnalité |
fix |
Correction de bug |
docs |
Documentation seule |
refactor |
Changement de code sans nouvelle fonctionnalité ni correction |
test |
Ajout/modification de tests |
chore |
Tâches diverses (config, dépendances…) |
perf |
Amélioration de performance |
Versionnage sémantique (SemVer)
MAJEUR . MINEUR . CORRECTIF → 2.4.1
| Partie | S'incrémente quand |
|---|---|
| MAJEUR | Changement incompatible avec les versions précédentes |
| MINEUR | Nouvelle fonctionnalité rétrocompatible |
| CORRECTIF | Correction de bug rétrocompatible |
Avec des commits feat/fix/BREAKING CHANGE bien écrits, des outils comme semantic-release calculent automatiquement le prochain numéro de version et génèrent le changelog.
Pré-versions et plages
1.4.0-beta.1 " pré-version ^1.4.0 " compatible avec 1.x.x (tant que MAJEUR ne change pas) ~1.4.0 " compatible avec 1.4.x seulement
Signaler un changement incompatible
feat(api)!: renommer le paramètre "id" en "userId" BREAKING CHANGE: le paramètre de requête `id` n'existe plus, utilisez `userId`.
Le ! après le type/la portée et/ou un pied BREAKING CHANGE: déclenchent automatiquement un incrément de version MAJEUR avec les outils de release automatisée.
Merci pour votre retour !