Explorer le versionnage sémantique

  • 4 minutes

L’une des méthodes prédominantes de contrôle de version est l’utilisation du contrôle de version sémantique (SemVer).

La gestion sémantique des versions n'est pas standardisé, mais offre un moyen cohérent d’exprimer l’intention et la sémantique d’une version particulière.

Elle décrit une version à des fins de compatibilité descendante avec les versions précédentes.

Format de contrôle de version sémantique

Le contrôle de version sémantique utilise un numéro de version en trois parties et une étiquette facultative.

Format Major.Minor.Patch

La version a la forme de Major.Minor.Patch qui correspond aux trois types de modifications abordés dans la section précédente.

Structure de version :

  • Major : premier nombre, indique les changements cassants.
  • Mineur : Deuxième nombre, indique de nouvelles fonctionnalités (rétrocompatibles).
  • Patch: Le troisième nombre indique les correctifs de bogues (compatible avec les versions antérieures).

Exemples de versions utilisant le schéma de gestion de version sémantique :

  • 1.0.0 - Version stable initiale
  • 3.7.129 - Version 3 avec de nombreuses mises à jour mineures et correctives
  • 2.0.0 - Version majeure 2 avec des changements cassants

Ces versions n’ont aucune étiquette.

Règles d’incrémentation de version

Quand incrémenter chaque nombre :

Incrémenter la majeure (X.0.0)

  • Modifications majeures : Apportez des modifications incompatibles à l’API.
  • Supprimer les fonctionnalités : Supprimez les fonctionnalités déconseillées.
  • Modifications architecturales : Refonte fondamentale.

Exemple :

  • 1.5.3 → 2.0.0 lorsque des changements majeurs sont introduits

Incrémenter mineur (x.Y.0)

  • Nouvelles fonctionnalités : Ajoutez des fonctionnalités de manière rétrocompatible.
  • Déprécier la fonctionnalité : Marquer les fonctionnalités comme déconseillées (mais toujours fonctionnelles).
  • Améliorations: Améliorations substantielles apportées aux fonctionnalités existantes.

Exemple :

  • 1.5.3 → 1.6.0 lors de l’ajout de nouvelles fonctionnalités

Incrémenter le correctif (x.y.Z)

  • Correctifs de bogues : Apportez des correctifs de bogues rétrocompatibles.
  • Correctifs de sécurité : Corrigez les vulnérabilités de sécurité.
  • Améliorations des performances : Optimisations mineures des performances.

Exemple :

  • 1.5.3 1.5.4→ pour les correctifs de bogues

Versions préliminaires

Pour les versions préliminaires, il est habituel d’utiliser une étiquette après le numéro de version standard.

Format d’étiquette

Une étiquette est un suffixe textuel séparé par un trait d’union du reste du numéro de version.

L’étiquette elle-même peut être n’importe quel texte décrivant la nature de la version préliminaire.

Structure d’étiquette :

Major.Minor.Patch-label

Étiquettes de préversion courantes

Voici quelques exemples : rc1, beta27et alpha, former des numéros de version comme :

  • 1.0.0-alpha - Version de développement anticipée, instable.
  • 1.0.0-beta - Fonctionnalité terminée, mais potentiellement buggy.
  • 1.0.0-beta.2 - Deuxième version bêta.
  • 1.0.0-rc1 - Candidat de mise en production, potentiellement prêt pour la mise en production.
  • 1.0.0-preview - Préversion pour les commentaires précoces.

Exemple de progression de version :

1.0.0-alpha.1
1.0.0-alpha.2
1.0.0-beta.1
1.0.0-beta.2
1.0.0-rc1
1.0.0-rc2
1.0.0

Conventions de libellé pour version préliminaire

Préfixes d’étiquette courants :

  • alpha: Version très précoce, attendez-vous à des bogues et à des changements majeurs.
  • Bêta: Fonctionnalité terminée, en cours de test.
  • rc (version candidate) : Version potentiellement finale, dernière phase de test.
  • Aperçu: Version préliminaire pour retour.
  • Dev: Instantané de développement.

Suffixes numériques :

Les étiquettes incluent souvent des nombres pour les préréleases séquentielles :

  • 1.0.0-beta.1 1.0.0-beta.2 → →1.0.0-beta.3

Utilisation de versions préliminaires

Les préversions sont un moyen courant de se préparer à la publication de la version sans étiquette du package.

Avantages des préversions

Commentaires précoces :

Les adopteurs précoces peuvent se baser sur une version préliminaire pour utiliser le nouveau package.

  • Intégration de test : Vérifiez que le package fonctionne avec les systèmes existants.
  • Signaler des problèmes : Recherchez les bogues avant la publication officielle.
  • Fournissez des commentaires : Suggérer des améliorations ou des modifications.

Déploiement progressif :

  • Lancement graduel : Lancez d’abord à un public restreint.
  • Atténuation des risques : Interceptez les problèmes avant la mise en production étendue.
  • Renforcement de la confiance : Renforcer la confiance en la stabilité.

Mises en garde pour la version préliminaire

En règle générale, l’utilisation d’une version préliminaire des packages et de leurs composants pour les logiciels publiés n’est pas une bonne idée.

Risques liés à l’utilisation de préversions en production :

  • Instabilité: Les préversions peuvent avoir des bogues non découverts.
  • Modifications disruptives : Les versions préliminaires futures peuvent introduire des modifications disruptives.
  • Aucune garantie : Aucune garantie de compatibilité descendante.
  • Limitations de prise en charge : Prise en charge limitée ou sans prise en charge des versions préliminaires.

Test des versions préliminaires

Il est judicieux d’attendre l’impact des nouveaux composants en créant une branche distincte dans le codebase et en utilisant la version préliminaire du package.

Meilleures pratiques pour tester les préréleases :

  • Branche distincte : Créez une branche de fonctionnalité pour les tests.
  • Environnement isolé : Test dans un environnement hors production.
  • Surveiller le comportement : Surveillez les problèmes inattendus de comportement ou de performances.
  • Problèmes de document : Suivez les problèmes trouvés.

Les chances sont qu’il y aura des modifications incompatibles d’une préversion à la version finale.

Métadonnées et informations de compilation

SemVer 2.0 prend également en charge les métadonnées de build ajoutées avec le signe plus :

1.0.0-beta.1+20231015.abc123

Métadonnées de build :

  • Non pris en compte dans la précédence de version : Deux versions diffèrent uniquement dans les métadonnées de build sont considérées comme égales.
  • À des fins d'information : Utile pour le suivi des numéros de build, des empreintes de validation.
  • Exemple:1.0.0+build.123 ou 1.0.0-beta+exp.sha.5114f85

Priorité des versions

SemVer définit des règles claires pour la priorité des versions :

Règles de comparaison

  1. Comparez les données majeures, mineures et correctives : dans cet ordre numériquement.
  2. Versions préliminaires : Toujours avoir une priorité inférieure à la version normale associée.
  3. Comparaison des étiquettes : Les segments alphanumériques comparés lexicalement, les segments numériques comparés numériquement.

Exemples dans l’ordre (le plus bas au plus élevé) :

1.0.0-alpha
1.0.0-alpha.1
1.0.0-alpha.beta
1.0.0-beta
1.0.0-beta.2
1.0.0-beta.11
1.0.0-rc.1
1.0.0
1.0.1
1.1.0
2.0.0

Avantages du contrôle de version sémantique

Communication claire :

  • Intention: Le numéro de version communique clairement la nature des modifications.
  • Compatibilité: Facile à déterminer si la mise à jour est sécurisée.
  • Prédictibilité: Contrôle de version cohérent entre les packages.

Gestion automatisée des dépendances :

  • Contraintes de version : Les gestionnaires de packages peuvent résoudre automatiquement les versions.
  • Mises à jour sécurisées : Les outils peuvent être mis à jour en toute sécurité vers des versions compatibles.
  • Résolution de conflit: Plus facile à résoudre les conflits de dépendances.

Adoption de l’écosystème :

  • Norme du secteur : Largement adoptés dans de nombreux écosystèmes.
  • Prise en charge des outils : Les gestionnaires de packages comprennent SemVer.
  • Attentes de la communauté : Les développeurs attendent la conformité SemVer.

Gestion sémantique des versions dans Azure Artifacts

Azure Artifacts prend en charge le contrôle de version sémantique sur tous les types de packages :

  • NuGet : Prise en charge native de SemVer 2.0.
  • npm : SemVer est la norme.
  • Maven: Compatible avec les principes semVer.
  • Python: PEP 440 est compatible avec les concepts SemVer.
  • Packages universels : Utilise SemVer 2.0.

Vues de flux et SemVer :

  • vue @Prerelease : Inclut automatiquement des versions avec des étiquettes.
  • vue @Release : N'inclut que les versions sans labels.
  • vue @Local : Affiche toutes les versions indépendamment de l’étiquette.

Implémentation du contrôle de version sémantique

Contrôle de version manuel :

  • Mettre à jour les fichiers de package : Mettez à jour manuellement la version dans package.json, .nuspecetc.
  • Valider avec une balise : Marquez la validation avec le numéro de version.

Contrôle de version automatisé :

# Using npm version command
npm version patch  # Increment patch: 1.0.0 -> 1.0.1
npm version minor  # Increment minor: 1.0.1 -> 1.1.0
npm version major  # Increment major: 1.1.0 -> 2.0.0

# With prerelease
npm version prerelease --preid=beta  # 1.0.0 -> 1.0.1-beta.0

Dans les pipelines CI/CD :

# Azure Pipelines example
- task: GitVersion@5
  inputs:
    runtime: "core"
    configFilePath: "GitVersion.yml"

- script: |
    echo "Semantic Version: $(GitVersion.SemVer)"
    echo "NuGet Version: $(GitVersion.NuGetVersion)"
  displayName: "Display version"

Voir aussi Semantic Versioning 2.0.0.