Gestion sémantique de version

Posté par Oliver (site web personnel) le 08 janvier 2015 à 19:16. Édité par Pierre Jarillon, Benoît Sibaud, ZeroHeure et palm123. Modéré par bubar🦥. Licence CC By‑SA.

Étiquettes :

jan.

2015

Les développeurs, intégrateurs et mainteneurs s'arrachent les cheveux quand ils ont à mettre à jour les versions des logiciels.

L'éternelle question La nouvelle version, est elle rétro-compatible ? pourrait se résoudre en se basant sur le nouveau numéro de version, mais chaque auteur de logiciel fait un peu comme il le sent.

C'est pour uniformiser ces règles, que Tom Preston-Werner (Gravatars et GitHub) a proposé la gestion sémantique de version (adoptée par de plus en plus de logiciels).

Dans la suite de la dépêche, ces règles sont résumées en 9 points.

Exemple: 2.15.4-rc.1+build.13

Trois numéros: majeur.mineur.patch
Et optionnellement un label de pré-livraison et un label de compilation pour plus de liberté
Le majeur est zéro (0.1.0) => n'importe quoi peut changer
Le majeur est un (1.0.0) => La première livraison officielle
Le majeur est incrémenté (2.0.0) => Changement incompatible de l'API
Le mineur est incrémenté (2.1.0) => Une nouvelle fonctionnalité
Le patch est incrémenté (2.1.1) => Correction de bug sans toucher l'API
Pour trier les versions dans l'ordre, les labels sont décomposés en identifiants séparés par des points
Chaque identifiant utilise des caractères parmi [0-9A-Za-z-]

Tous les détails sont sur le site officiel.

Il est possible de proposer des évolutions en clonant le projet Git, puis en soumettant un pull request. Mais les règles sont maintenant bien abouties et stables. Néanmoins nombreux sont ceux qui souhaiteraient avoir la possibilité de ne pas indiquer le numéro de patch (quand ce n'est pas une version patchée) ou d'ajouter un quatrième numéro…

Et à quoi reconnaît-on qu'un logiciel respecte cette règle ?

Pas d'indication particulière dans la version à part la présence des trois nombres et le respect des conventions. Il est donc nécessaire de lire au moins de temps en temps la documentation des logiciels. Comme par exemple, C'est vers la fin du readme.md de TinyXML-2 qu'est mentionné cette gestion de version.

Une proposition de préfixe ?

Personnellement, je préfixe souvent les versions par la lettre v (v2.15.4). Nous pourrions peut être proposer de préfixer par sv (sv2.15.4) quand les règles de "Semantic Versioning" sont appliquées… Bof…

Et vous qu'en pensez-vous ?
Séduit, convaincu, adopté ?
L'utilisez vous déjà dans vos logiciels ? (libres ou internes à vos entreprise)

Aller plus loin

Site officiel SemVer (828 clics)
Blog de Tom Preston-Werner home (166 clics)

# Gestion sémantique de version ? WTF ?

Posté par GeneralZod le 08 janvier 2015 à 20:20. Évalué à 10.

http://apr.apache.org/versioning.html
Tom Preston-Werner avait même pas atteint la puberté que beaucoup de projets libres utilisaient et avaient même formalisé ce schéma de versionning. Le gusse n'a rien inventé ou même formalisé, juste évangélisé les communautés Ruby ou Java à gérer proprement leurs versions. Certes, c'est une grosse avancée dans ces communautés où c'était vraiment le bordel en la matière.
- [^] # Re: Gestion sémantique de version ? WTF ?
  
  Posté par Sébastien Le Ray le 08 janvier 2015 à 21:07. Évalué à 2.
  
  T'es au courant qu'apache fournit des libs java incontournables et qu'à l'époque du jdk 1.3 c'étaient eux qui rendaient le langage utilisable? Donc je pense pas qu'il y ait eu besoin d'un autre gugus pour évangéliser…
  - [^] # Re: Gestion sémantique de version ? WTF ?
    
    Posté par GeneralZod le 08 janvier 2015 à 21:20. Évalué à 3.
    
    En pratique, la plupart des projets Java gérent très mal leur schéma de version (y compris la JVM qui péte lors de mises à jours PATCH) et je ne m'exprimerais pas sur les projets non-libre où c'est le pire.
    Et ne me lancez pas sur Maven qui a encouragé les pires abus en la matière …
    - [^] # Re: Gestion sémantique de version ? WTF ?
      
      Posté par ariasuni le 09 janvier 2015 à 01:11. Évalué à 6.
      
      Je suis quand même assez curieux, à la vue des trois commentaires précédents, de savoir un peu de quoi vous parlez plus précisément.
      
      Écrit en Bépo selon l’orthographe de 1990
# Changelog?

Posté par fero14041 le 08 janvier 2015 à 20:45. Évalué à 3.

Apparemment, la version 2 de la "norme" est sortie assez récemment. Mais où peut-on trouver un changelog lisible, ailleurs que celui du dépôt git? (parce que bon, indiquer "on a changé ~~de version~~l'API", c'est que la moitié du boulot…)
- [^] # Re: Changelog?
  
  Posté par chimrod (site web personnel) le 08 janvier 2015 à 21:16. Évalué à 2.
  
  Et ils ont cassé la compatibilité avec la version 1 ? (-:
  
  C'est aussi le modèle que nous avons suivi (sans le savoir) en le couplant a la gestion des versions sur svn (oui j'ai sais…) :
  
  nos branches sont versionnees sur les deux premier numero, alors que les tags, qui correspondent aux versions livrées, incluent également le 3ème numéro de la version. Finalement ca marche assez bien : tant que la branche reste ouverte, on se donne le droit d'apporter des corrections, par contre la compatibilité de l'Api entre deux branches n'est pas garantie.
  - [^] # Re: Changelog?
    
    Posté par ariasuni le 08 janvier 2015 à 22:17. Évalué à 2.
    
    svn (oui j'ai sais…)
    
    Tu essaie quoi? :P
    
    Écrit en Bépo selon l’orthographe de 1990
    - [^] # Re: Changelog?
      
      Posté par chimrod (site web personnel) le 08 janvier 2015 à 23:25. Évalué à 5.
      
      Je sais maintenant qu'écrire des commentaires dans le train avec son smartphone n'est pas une bonne idée !
# Et l’ABI, c’est du poulet ?

Posté par whity le 08 janvier 2015 à 22:39. Évalué à 4.

Pas un mot sur l’ABI, alors qu’on parle de rétrocompatibilité, c’est un gros lol.

Il est au courant, le monsieur, qu’on peut :
- casser l’API sans casser l’ABI
- casser l’ABI sans casser l’API
- casser les deux à la fois
- préserver les deux à la fois

Bon courage pour faire un schéma de versioning qui fasse la différence (car elle est ultra-importante) avec seulement 3 chiffres…

Et sinon, +1 à tous ceux qui ont déclaré que c’était déjà majoritairement utilisé dans les projets qui ne différencient pas ABI/API. Rien de bien nouveau.

Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
- [^] # Re: Et l’ABI, c’est du poulet ?
  
  Posté par David Demelier (site web personnel) le 09 janvier 2015 à 08:47. Évalué à 4.
  
  l'ABI ne concerne pas tous les langages… Par exemple en python/ruby/perl/js parler d'ABI n'a presque pas de sens. Semver n'est pas destiné qu'aux langages natifs.
  
  De plus l'ABI elle est normalement gérée par le numéro de version de la bibliothèque partagée. Tu sais le dernier numéro de liba.so.0.2. Et ce dernier n'a rien à voir avec la version de la bibliothèque elle même. Lorsqu'on utilise une bibliothèque statique, le problème ne se pose même pas.
  
  git is great because linus did it, mercurial is better because he didn't
# PEP 440 - Version Identification and Dependency Specification

Posté par Victor STINNER (site web personnel) le 09 janvier 2015 à 02:36. Évalué à 10.

Pendant ce temps dans la communauté Python, un document écrit en mars 2013 normalise les numéros de version :
https://www.python.org/dev/peps/pep-0440/

Le module distutils.version qui fait parti de distlib implémente cette PEP. C'est-à-dire qu'on peut valider qu'un numéro de version respecte une PEP, mais surtout comparer deux numéros de version.

Il est maintenant plus fiable de mettre à jour des modules dans un environnement virtuel géré par pip (le gestionnaire de modules Python de référence).

Vu la longueur de la PEP, on se rend compte de l'originalité dont font preuve les développeurs pour numéroter leurs logiciels !
# "Gestion"

Posté par Antoine le 09 janvier 2015 à 03:23. Évalué à 7.

Apparemment, quand on ne sait pas comment dire ce qu'on veut dire, on utilise le mot "gestion" en pensant que ça donne l'air qu'on maîtrise le sujet (qu'on gère, quoi… moi, un type qui me dit qu'il "gère", j'en déduis qu'il ne gère rien, en fait, et qu'il est sûrement un peu paumé). Et des hordes de programmeurs débutants appellent leur première classe "Manager" (parce qu'en anglais ça fait plus pro). Elle fait quoi ta classe ? Elle manage.

Évidemment, si on va voir "Gestion de versions" dans Wikipédia, on constate que cela dénote les outils du type Mercurial, Git, Subversion… et non le schéma de nommage des versions d'un logiciel.

Sinon, la page d'origine (http://semver.org) s'appelle "Semantic Versioning" et non "Semantic Version Management". Ouf !
- [^] # Re: "Gestion"
  
  Posté par Oliver (site web personnel) le 09 janvier 2015 à 15:18. Évalué à -1.
  J'essaye de comprendre ce qui te déranges, mais tu n'es pas très clair sur le point que tu critiques :
  1. La traduction Gestion sémantique de version ?
  2. Le raccourci que j'ai osé prendre avec l'exemple TinyXML ?
  3. Le logo d'un outil de gestion de version associé à cette dépêche ?
  4. Un coup de gueule en général contre l'utilisation abusive du mot gestion (et Manager) ?
  5. Un peu de tout ça, mais rien de bien précis ?
  J'espère que c'est surtout le premier point qui te gènes (car de mon point de vue, c'est le point qui peut apporter le plus de valeur ajoutée dans les commentaires de cette dépêche). Si c'est bien ce premier point, tu peux continuer à lire mon commentaire :-)
  
  Oui, la traduction de Semantic versioning en Gestion sémantique de version est maladroite car le mot gestion change un peu le sens. Attention ne ce n'est pas Gestion de version, nous sommes bien d'accord ?
  
  Donc d'après ce que je comprends, tu préférerais traduire versioning en schéma de nommage des versions, c'est bien cela ?
  
  C'est bien de donner ton avis, de critiquer cette formulation, mais que proposes-tu pour améliorer la traduction ? Qu'est ce que tu as de mieux ?
  
  On pourrait imaginer Sémantique du schéma de nommage de version…
  
  Mais ce n'est pas aussi court/sexy que Semantic versioning !
  
  Et pourquoi pas Sémantique de versionnage ?
  
  Soyons ouvert à toutes propositions, nous pourrions ainsi proposer une évolution à semver-2.0.0.
  
  Des idées ?
  
  Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)
  - [^] # Re: "Gestion"
    
    Posté par Antoine le 10 janvier 2015 à 02:07. Évalué à 1.
    
    Donc d'après ce que je comprends, tu préférerais traduire versioning en schéma de nommage des versions, c'est bien cela ?
    
    C'est bien de donner ton avis, de critiquer cette formulation, mais que proposes-tu pour améliorer la traduction ?
    
    Eh bien, c'est marqué au-dessus…
    On peut aussi imaginer numérotation sémantique des versions ou tout simplement versionnage sémantique.
# Liens supplémentaires

Posté par Benoît Sibaud (site web personnel) le 09 janvier 2015 à 08:57. Évalué à 8.
- Versions par libtool
- 7 familles de versions citées par Wikipédia
# Second problème qui passe inaperçu

Posté par Jiehong (site web personnel) le 09 janvier 2015 à 09:11. Évalué à 4.

Quand je vois une version d'un logiciel ou d'une bibliothèque, je me pose souvent 2 questions :

1. Est-ce une version récente ?
2. Cette version casse-t-elle l'ABI ou l'API ?

Une version dite « sémantique » ne répond qu'au deuxième problème (et partiellement), alors qu'une version en « 2015.01 » ne répond qu'à la première question.

Il faudrait sûrement un mélange des deux pour y voir un peu plus clair.
- [^] # Re: Second problème qui passe inaperçu
  
  Posté par Oliver (site web personnel) le 09 janvier 2015 à 15:29. Évalué à 2.
  Bonne idée :-)
  
  Que penses-tu de 2.15.4+2015.01
  - 2.15.4 = les trois numéros majeur, mineur et patch
  - 2015.01 = ce que j'ai désigné label de compilation dans la dépêche, ce que semver.org traduit en méta-données de construction dont l'original en anglais est build metadata
  C'est autorisé par les règles Semantic Versioning 2.0.0. Après il faudrait que de plus en plus d'auteurs adoptent de mettre la date dans les données de construction…
  
  Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)
# Bof

Posté par barmic le 09 janvier 2015 à 09:35. Évalué à 4.

Et vous qu'en pensez-vous ?

Que ça existe déjà depuis des lustres, sauf qu'on parle de majeur.mineur.micro

Séduit, convaincu, adopté ?
L'utilisez vous déjà dans vos logiciels ?

Non, pas moi qui choisi au boulot.

Personnellement, s'il y a besoin de définir une API, alors il vaut mieux AMHA carrément avec des numéros de version sur cette API. De la même manière que ce qui est fait quand on utilise (en implémentant ou en consommant) une API ("Le logiciel super-patate en version 3.1415 gère telle API en version 12.256 et le format bidule en version 42.42). Ça permet de gérer à la fois des cassages de multiples API, ABI et format de fichier et ça améliore l'intéropérabilité parce qu'un autre logiciel peut utiliser ou consommer cette interface en référençant le numéro de version en question.

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
- [^] # Re: Bof
  
  Posté par Oliver (site web personnel) le 09 janvier 2015 à 15:53. Évalué à 1.
  Je ne suis pas sûr d'avoir bien saisi. J'ai l'impression que cela traite de la gestion de dépendances :
```
    super-patate        v3.1415
      \__ telle-API     v12.256 
      \__ format-bidule v42.42
```
  Un an après, toutes les briques ont un peu évolué et nous avons :
```
    super-patate        v3.2000
      \__ telle-API     v12.300 
      \__ format-bidule v42.50
```
  Donc, la version de super-patate dépend d'une version bien spécifique de chacune de ses dépendances.
  
  Par conséquent, quand on livre (une API, une ABI, une bibliothèque, un protocole…), il faudrait aussi fournir les versions des dépendance et pas seulement la version du livrable.
  
  Si c'est bien de cela, alors nous sommes d'accord.
  Par contre, la gestion des dépendances est un autre sujet que la numérotation des version.
  
  Si je suis à côté de la plaque, ne pas hésiter à expliquer, vulgariser, développer…
  
  Commentaire sous licence Creative Commons Zero CC0 1.0 Universal (Public Domain Dedication)
  - [^] # Re: Bof
    
    Posté par barmic le 09 janvier 2015 à 16:53. Évalué à 4.
    
    Je vais l'expliciter un peu plus clairement. Le problème c'est que l'on cherche à créer un indexe pour des choses qui n'ont pas nécessairement le même cycle de vie. Tu peux le voir comme une dépendance mais faut bien comprendre que ces statique.
    
    Quand tu prend le dernier LibO, il va pouvoir lire et écrire des documents OpenDocuments 1.2 (par exemple je sais plus quelle est la dernière version). Si demain, la document fundation sort un LibO 5 (avec par exemple une refonte complète de sont interface) elle gèrera toujours OpenDocument 1.2.
    
    Ce que je veux dire c'est que ce n'est pas que tu livre en même temps, c'est ton logiciel. C'est juste une façon simple de discuter/communiquer de ses interfaces.
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Commentaire supprimé

Posté par Anonyme le 09 janvier 2015 à 13:15. Évalué à -10.

Ce commentaire a été supprimé par l’équipe de modération.
# ferver

Posté par CrEv (site web personnel) le 09 janvier 2015 à 14:25. Évalué à 5.

Je ne suis pas fana de semver. Entre autre je trouve que c'est souvent inutilement complexe. Franchement, beaucoup de softs ont vraiment besoin de x.y.z et de règles pour les trois ? Je ne pense pas.
Et les règles, si elles paraissent bien au début, sont loin d'être si faciles à gérer.

Voir par exemple http://www.jongleberry.com/semver-has-failed-us.html du mainteneur de express, qui introduit ferver, Fear-Driven Versionning

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.