Gestion sémantique de version

Posté par (page perso) . Édité par Pierre Jarillon, Benoît Sibaud, ZeroHeure et palm123. Modéré par tankey. Licence CC by-sa
27
8
jan.
2015
Gestion de versions

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

  1. Trois numéros: majeur.mineur.patch
  2. Et optionnellement un label de pré-livraison et un label de compilation pour plus de liberté
  3. Le majeur est zéro (0.1.0) => n'importe quoi peut changer
  4. Le majeur est un (1.0.0) => La première livraison officielle
  5. Le majeur est incrémenté (2.0.0) => Changement incompatible de l'API
  6. Le mineur est incrémenté (2.1.0) => Une nouvelle fonctionnalité
  7. Le patch est incrémenté (2.1.1) => Correction de bug sans toucher l'API
  8. Pour trier les versions dans l'ordre, les labels sont décomposés en identifiants séparés par des points
  9. 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)
  • # Gestion sémantique de version ? WTF ?

    Posté par . É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 . É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 . É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 …

  • # Changelog?

    Posté par . É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 versionl'API", c'est que la moitié du boulot…)

    • [^] # Re: Changelog?

      Posté par (page perso) . É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 (page perso) . Évalué à 2.

        svn (oui j'ai sais…)

        Tu essaie quoi? :P

        Écrit en Bépo selon l’orthographe de 1990

        • [^] # Re: Changelog?

          Posté par (page perso) . É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 . É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 (page perso) . É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.

      l'azerty est ce que subversion est aux SCMs

  • # PEP 440 - Version Identification and Dependency Specification

    Posté par (page perso) . É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 . É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 (page perso) . É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 . É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 (page perso) . Évalué à 8.

  • # Second problème qui passe inaperçu

    Posté par (page perso) . É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 (page perso) . É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 . É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 (page perso) . É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 . É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 . Évalué à -10.

    Ce commentaire a été supprimé par l'équipe de modération.

  • # ferver

    Posté par (page perso) . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.