CalVer (Calendar Versioning)

"C'est un changement majeur ou mineur ?" Si cette question revient à chaque release dans votre équipe, c'est probablement que le Semantic Versioning (SemVer) n'est pas adapté à votre contexte. Le Calendar Versioning (CalVer) propose une alternative simple : le numéro de version, c'est la date de sortie.

Le problème avec SemVer

SemVer (MAJOR.MINOR.PATCH) est le standard pour les bibliothèques et les frameworks. La version 2.4.1 signifie : 2e version majeure (breaking changes), 4e ajout de fonctionnalités, 1er correctif. C'est clair, structuré, et utile quand vos utilisateurs sont des développeurs qui intègrent votre code.

Mais pour beaucoup de projets, SemVer pose des problèmes :

• Débats interminables — "Est-ce que ce changement d'UI est une feature ou un fix ?" "Ce refactoring justifie-t-il un bump mineur ?"
• Versions qui ne veulent rien dire — la version 14.7.3 d'une application web n'apporte aucune information utile à l'utilisateur final
• Pas de notion de temps — impossible de savoir si 3.2.1 date d'hier ou d'il y a deux ans

CalVer : le versioning par la date

CalVer utilise la date de sortie comme base du numéro de version. Le format varie selon les projets, mais le principe reste le même : la version vous dit quand elle a été publiée.

Les formats courants

Il n'y a pas de format unique imposé. Chaque projet choisit ce qui correspond à son rythme de release.

Exemples concrets

Ubuntu utilise YY.MM — Ubuntu 24.04 est sorti en avril 2024. Pas besoin de documentation : le numéro de version vous dit exactement quand il a été publié. Les versions LTS (Long Term Support) sont les .04 des années paires.

pip (le gestionnaire de paquets Python) utilise YY.N — pip 24.2 est la deuxième release de 2024.

Unity utilise YYYY.N — Unity 2026.1 est la première release de 2026.

Terraform est passé de SemVer (0.15, 1.0) à CalVer à partir de la version 1.6, puis a adopté un format YY.MM pour les versions suivantes.

CalVer vs SemVer : comment choisir

Utilisez SemVer quand :

• Votre logiciel est une bibliothèque ou un framework utilisé comme dépendance
• Vos utilisateurs ont besoin de savoir si une mise à jour casse leur code
• La compatibilité entre versions est un enjeu critique (API publiques)

Utilisez CalVer quand :

• Votre logiciel est une application (web, mobile, desktop)
• Vous avez un cycle de release régulier (toutes les semaines, tous les mois)
• Vos utilisateurs ne gèrent pas de compatibilité (ils utilisent toujours la dernière version)
• Vous voulez éliminer les débats sur le type de changement

Implémenter CalVer

En pratique, CalVer est trivial à mettre en place. Dans votre CI/CD :

# Format YYYY.MM.DD
VERSION=$(date +%Y.%m.%d)
 
# Avec un compteur pour les hotfixes du même jour
VERSION=$(date +%Y.%m.%d).1
 
# Format YYYY.MM avec compteur incrémental
VERSION="2026.03.$(git rev-list --count HEAD --since='2026-03-01')"

Pas de fichier VERSION à maintenir manuellement. Pas de script qui analyse les commits pour deviner le type de changement. La date est la date.

Les limites de CalVer

CalVer n'est pas parfait. Il ne communique pas la nature du changement. Un utilisateur qui voit 2026.03.07 ne sait pas s'il s'agit d'un correctif de bug ou d'une refonte majeure. Pour une bibliothèque avec des breaking changes, c'est un vrai problème — vos utilisateurs ont besoin de savoir avant de mettre à jour.

C'est pourquoi certains projets utilisent un format hybride : CalVer pour la version principale, avec un suffixe pour les correctifs (2026.03-hotfix.1), ou SemVer pour les bibliothèques et CalVer pour les applications internes.

CalVer ne remplace pas SemVer — il le complète pour les cas où SemVer n'apporte pas de valeur. Si vos releases sont régulières, si vos utilisateurs sont des humains et pas des gestionnaires de paquets, et si votre équipe perd du temps à débattre entre MAJOR et MINOR, CalVer simplifie votre workflow en éliminant une décision inutile. La version, c'est la date. Point.