Release Management¶

Structurer la numerotation des versions, automatiser les changelogs et orchestrer la publication des releases depuis l'historique Git.

Semantic Versioning¶

Le Semantic Versioning (SemVer) définit un format de version a trois composantes : MAJOR.MINOR.PATCH.

Composante	Incremente quand...	Exemple
`MAJOR`	Une API publique change de façon incompatible (breaking)	`1.4.2` → `2.0.0`
`MINOR`	Une nouvelle fonctionnalité est ajoutee (compatible)	`1.4.2` → `1.5.0`
`PATCH`	Un bug est corrige sans changer l'interface	`1.4.2` → `1.4.3`

Pre-releases¶

Les pre-releases se notent avec un suffixe séparé par un tiret :

1.0.0-alpha.1
1.0.0-beta.3
1.0.0-rc.1
1.0.0

SemVer ne s'applique qu'aux APIs publiques

Pour un service interne sans contrat d'API externe, SemVer reste utile comme convention d'équipe, mais le MAJOR n'a de sens que si d'autres équipes consomment votre API.

Conventional Commits¶

Les Conventional Commits définissent un format de message de commit qui permet d'automatiser la détermination du prochain numéro de version.

<type>(<scope>): <description>

[body optionnel]

[footers optionnels]

Les types courants et leur impact sur le versioning :

Type	Exemple	Impact SemVer
`feat`	`feat(auth): add OAuth2 support`	MINOR
`fix`	`fix(api): correct null response`	PATCH
`docs`	`docs: update README`	Aucun
`refactor`	`refactor(core): extract service`	Aucun
`BREAKING`	`feat!: remove legacy endpoint`	MAJOR

Un footer BREAKING CHANGE: ou un ! après le type déclenche une incrementation MAJOR.

Pour la définition complète du format, voir Conventional Commits — Fondamentaux.

Les commits deviennent des données

Avec les Conventional Commits, votre historique Git devient une base de données structurée. Les outils de release peuvent l'interroger pour déterminer automatiquement la prochaine version et générer le changelog.

Changelogs automatiques¶

Le changelog est généré depuis les commits conventionnels. Il est structure par version et par type de changement.

## [2.1.0] - 2026-04-13

### Features

- **auth**: add OAuth2 support (#142)
- **api**: add pagination to list endpoints (#138)

### Bug Fixes

- **api**: correct null response on missing resource (#145)
- **ui**: fix date formatting in timezone UTC+2 (#143)

### Documentation

- update deployment guide (#140)

Audience : le changelog est destine aux consommateurs de la librairie ou du service. Il doit être clair, lisible et ne pas inclure les commits de type chore, ci ou docs par défaut.

Ne pas écrire le changelog à la main

Un changelog maintenu manuellement est toujours en retard et souvent incomplet. Automatisez-le depuis les commits : la discipline des Conventional Commits devient alors directement visible.

Tags Git¶

Un tag Git marque un commit comme point de référence nomme. Il existe deux types :

Tag léger : un simple pointeur sur un commit.

git tag v1.4.2

Tag annote : un objet Git a part entière avec message, auteur et date. Signe avec GPG.

git tag -a v1.4.2 -m "Release 1.4.2 — hotfix authentification"
git tag -s v1.4.2 -m "Release 1.4.2"  # avec signature GPG

Toujours utiliser des tags annotes pour les releases

Les tags annotes sont stockes en tant qu'objets dans Git et peuvent être signes. Les tags légers sont des alias temporaires. Pour marquer une release, privilegiez toujours le tag annote.

Release branches¶

Les release branches sont utiles quand plusieurs versions majeures sont maintenues en parallèle, ou quand le processus de release nécessité une periode de stabilisation.

gitGraph
    commit id: "feat: nouvelle API"
    commit id: "fix: correction auth"
    branch release/1.5
    checkout release/1.5
    commit id: "chore: bump 1.5.0"
    commit id: "fix: hotfix critique"
    commit id: "chore: bump 1.5.1" tag: "v1.5.1"
    checkout main
    merge release/1.5
    commit id: "feat: prochaine iteration"

Workflow complet¶

graph LR
    A["Commits\nConventionnels"] --> B["Tag Git\nannoté"]
    B --> C["Changelog\ngeneré"]
    C --> D["Release Notes\npubliees"]
    D --> E["Artefact\npublié"]
    style E fill:#2ecc71,color:#fff

Outils¶

Outil	Description	Lien
semantic-release	Automatise tout le cycle : version, changelog, tag, publish	semantic-release.gitbook.io
conventional-changelog	Generateur de changelog depuis les commits conventionnels	github.com/conventional-changelog
standard-version	Alternative simple à semantic-release, sans CI obligatoire	github.com/conventional-changelog/standard-version
release-please	Outil Google pour PR de release automatiques (GitHub/GitLab)	github.com/googleapis/release-please