La gestion des versions est un aspect fondamental du développement logiciel. Elle permet de suivre l’évolution d’un projet, de signaler les changements, et de maintenir la stabilité des intégrations. Le versionnage sémantique, aussi appelé SemVer, est une convention formelle conçue pour numéroter les versions de manière prévisible et explicite. En codifiant les règles de compatibilité, il facilite la gestion des dépendances et l’automatisation des mises à jour. Cet article présente les principes clés de SemVer, son format, et son usage dans les cycles de développement.

Qu’est-ce que SemVer ?

Le concept de SemVer a été créé en 2010 par Tom Preston-Werner, cofondateur de GitHub. Il est né du besoin d’harmoniser la manière dont les logiciels sont versionnés. L’objectif était double : clarifier les conséquences d’un changement de version pour faciliter la compréhension des impacts d’une mise à jour, et améliorer la gestion des dépendances dans les projets. Aujourd’hui, SemVer est massivement utilisé dans l’univers open source et adopté par de nombreux gestionnaires de paquets comme NPM pour JavaScript, Composer pour PHP, les frameworks JavaScript, les modules Go, etc.

Le format SemVer

Une version suivant la convention SemVer s’écrit sous la forme MAJOR.MINOR.PATCH. Il est possible d’y ajouter un suffixe pour signaler une préversion, comme alpha ou beta.

Le numéro MAJOR indique une modification majeure, souvent synonyme de refonte, suppression ou modification importante des fonctionnalités existantes. Cela peut rendre les dépendances ou intégrations antérieures non compatibles. Par exemple, passer de 2.8.5 à 3.0.0 signifie une rupture potentielle avec les versions précédentes.

Le numéro MINOR correspond à l’ajout de nouvelles fonctionnalités tout en conservant la rétro compatibilité. Les anciennes fonctions restent accessibles et inchangées. Un passage de 2.5.0 à 2.6.0 illustre ce type d’évolution.

Le numéro PATCH concerne les corrections de bugs ou les optimisations légères, sans ajout de fonctionnalités et sans altération du comportement attendu du logiciel. Une mise à jour de 2.5.2 à 2.5.3 entre dans cette catégorie.

Les versions préliminaires (pre-releases)

Avant qu’une version stable ne soit diffusée, plusieurs étapes intermédiaires peuvent voir le jour. Ces versions sont signalées par un suffixe, comme dans 2.0.0-beta ou 3.1.0-alpha.1. Elles servent à tester de nouvelles fonctionnalités, détecter les bugs ou problèmes de compatibilité en amont, et récolter les retours des développeurs ou de la communauté.

La version Alpha

La version alpha représente la toute première étape de développement, qu’elle soit publique ou en interne. Le code est encore instable, souvent incomplet, et peut contenir des fonctions non finalisées, des erreurs majeures ou des comportements inattendus. Elle est utilisée pour expérimenter de nouvelles idées, mais reste à éviter en environnement de production.

La version Beta

Une version beta est plus avancée. Les fonctionnalités principales sont généralement en place, et le code plus stable que dans une version alpha, même s’il peut encore présenter des bugs. Elle est utilisée pour les tests utilisateurs, la collecte de feedbacks de la communauté, et les tests d’intégration avec des outils tiers. En production, elle doit être utilisée avec précaution, souvent dans un cadre de préproduction.

La version Release Candidate (RC)

Une Release Candidate (RC) est une version quasi finale, prête à être livrée. Toutes les fonctionnalités sont implémentées, et la priorité est donnée à la stabilité. Seuls les défauts critiques sont corrigés à ce stade. Si aucun problème majeur n’est identifié, cette version devient la version stable.

Exemple d’un cycle de développement complet

Un cycle de développement typique commence par une version alpha (par exemple 2.0.0-alpha), suivie d’une version beta (2.0.0-beta), puis d’une ou plusieurs Release Candidates (2.0.0-rc.1, 2.0.0-rc.2) jusqu’à la publication finale (2.0.0).

Comprendre la rétrocompatibilité

Une mise à jour est dite rétro compatible lorsqu’elle ne casse pas le fonctionnement du code basé sur une version précédente. À l’inverse, une mise à jour non rétro compatible nécessitera une adaptation du code de l’utilisateur pour fonctionner avec la nouvelle version.