Gestion sémantique de version

Un logiciel, une application ou un site web (voire un fichier photoshop?) est souvent assorti d’un numéro à trois chiffres, du type 1.5.2.

Pas un hasard, mais une version. Comment ça marche?

Comment l’appliquer à un fichier?

Principe de la gestion sémantique de version

Le principe est assez simple, et décrit dans le document Gestion sémantique de version 2.0.0 (oui, ce document possède lui aussi une version).

Il est composé de trois chiffres:

• le premier étant le numéro de version majeur
• le second mineur,
• et le troisième un numéro de correctif.

Quand changer de numéro?

• le numéro de version MAJEUR quand il y a des changements rétro-incompatibles,
• le numéro de version MINEUR quand il y a des changements rétro-compatibles,
• le numéro de version de CORRECTIF quand il y a des corrections d’anomalies rétro-compatibles

Rétro incompatible signifie que si vous passez à cette version, vous risquez de ne pas pouvoir revenir à la version précédente.

Précisons qu’il sera souvent possible de revenir en arrière, surtout si on a pensé à faire de sérieuses sauvegardes au préalable. Ce qui est indispensable de toutes façon avant tout changement de version.

Petit exemple

Si on est en version 1.2.3, on pourra ainsi passer:

• au 1.2.4 si on corrige un petit bug
• au 1.3.0 si on ajoute une petite fonctionnalité qui n’a que peu d’incidence sur le fonctionnement général
• au 2.0.0 si on a fait une grosse refonte, qui peut par exemple avoir modifié la structure des bases de données

Le document en question cite quelques autres exemples.

Précisons au passage que le document gestion sémantique de version est écrit par Tom Preston-Werner, cofondateur de GitHub (système de gestion de version du code basé sur Git).

Appliqué à un fichier?

Disons le d’entrée de jeu, ceci est évidement un exemple qui doit être considéré comme une source d’inspiration.

Nous allons donc appliquer ce système de version à un historique de sauvegarde de fichier Photoshop (au hasard, ce qui fera sourire certains qui connaissent mon utilisation de Photoshop; mais cela peut s’appliquer à de nombreux cas).

Nous pourrions avoir, dans un dossier du nom du client, dans un sous dossier pour le projet donné, pour un fichier logo:

• client/projet/logo-0.1.0.psd première version du fichier
• client/projet/logo-0.1.1.psd petite retouche
• client/projet/logo-0.1.2.psd petite retouche
• client/projet/logo-0.2.0.psd grosse retouche
• client/projet/logo-1.0.0.psd première présentation au client
• client/projet/logo-1.1.0.psd retouche après retour client
• client/projet/logo-1.2.0.psd etc
• client/projet/logo-2.0.0.psd version finale (à ce jour)
• etc.

Bien entendu, dès qu’un fichier change de version, la version précédente devient intouchable (sauf pour consultation). On peut même envisager de le mettre en lecture seule pour éviter les erreurs.

L’avantage est multiple:

• on peut discuter sur des bases saines d’un fichier donné. Choisissez:
  1. mais si, c’est le fichier avec le truc rouge que je t’ai envoyé mardi.. ou mercredi…
  2. mais si, c’est le fichier 1.2.4
• on peut facilement tracer les diverses modification et éventuellement revenir en arrière

Rien ne s’oppose à ce que l’on puisse ajouter des informations dans le nom du fichier, pour y ajouter des dates ou le nom des intervenants. Même si pour cela, il est préférable d’utiliser un fichier release.txt (ou une section release dans un fichier readme.md), voir pour rester dans l’exemple Photoshop, utiliser les données IPTC pour y ajouter l’historique de chaque version (menu Fichier > informations)…

PS: article inspiré suite à ce poster.