Journal numérotation (version) d'application

Posté par  (site web personnel) .
Étiquettes : aucune
1
7
déc.
2005
Bonjour,

Je réflechissais dernièrement à la manière de numéroter une appli (ie les numéros de version).
Et je me rend compte qu'il y a un peu de tout et n'importe quoi qui existe.

Il y a la classique x.y.z qu'on peut décliner suivant différents modèles avec x toujours un majeur s'incrémentant rarement. Mais y et / ou z peuvent soient s'incrémenter "normalement" soit, et de moins en moins je trouve, représenter l'avancement de la version (le nombre represente le pourcentage d'avancement)
Je trouve cette dernière très pratique en tant qu'"utilisateur" mais quand il s'agit de donner ce nombre c'est parfois plus compliqué.
On peut aussi varié en ayant z simplement un numéro de build / de révision (numéro révision svn par exemple) qui permet à lui seul d'identifier (mais manière peu explicite) exactement la version.

On trouve aussi le classique yyyy.mm.dd mais je trouve ça franchement pas beau (avis totalement subjectif ;-)) et surtout ne représentant pas grand chose de l'évolution du projet.

Il y a ensuite la version "java" ou "marketing" :
1.2 (je crois qu'elle existe mais en écrivant j'ai un doute...)
1.4 = 2
1.5 = 5

j'ai jamais vu un soft passer aussi facilement les version majeurs... ;-)

Enfin il y a quelques systèmes très zarb, le dernier que j'ai vu est la numérotation de pugs (une implémentation de perl6 en Haskell)
Les versions s'enchainent en convergeant vers 2*π :
chaque digit dans la version mineur représente une milestone (désolé je voyais pas trop comment le traduire à part par "étape importante" mais personne aurait compris ;-) ). Le troisième digit est incrémenté à chaque release.

Ce qui donne (car là ça doit pas être très clair :
* 6.0: Initial release.
* 6.2: Basic IO and control flow elements; mutable variables; assignment.
* 6.28: Classes and traits.
* 6.283: Rules and Grammars.
* 6.2831: Type system and linking.
* 6.28318: Macros.
* 6.283185: Port Pugs to Perl 6, if needed.

(ceci provient de http://svn.perl.org/perl6/pugs/trunk/docs/01Overview.html )

comme je disais, il y a de tout et même du n'importe quoi...

et vous, comment numérotez-vous vos versions ?
  • # java

    Posté par  . Évalué à 2.

    Il y a ensuite la version "java" ou "marketing" :
    1.2 (je crois qu'elle existe mais en écrivant j'ai un doute...)
    1.4 = 2
    1.5 = 5


    java 1 = java 1.0
    java2 = java 1.2 (premiere version reellement utilisable de java, judicieusement nommée java 2 du coup)
    toujours du java 2 = java 1.3, 1.4
    java5 = java 1.5 => evolution du langage etc. justifiant un changement version majeur.

    Sinon, je suis partisan du mois.annee pour les projets tres long terme (histoire de savoir quand ils sont sortis, ce qui est plus pertinent comme info, genre pour une distrib) et du majeur.mineur pour les autres, mineur etant strictement inferieur a 10.

    Ca c'est pour les numerotations "publique", pour des numerotations interne, n'importe quoi qui donne l'info pertinente relative a la version.
    • [^] # Re: java

      Posté par  (site web personnel) . Évalué à 3.

      java 1 = java 1.0
      java2 = java 1.2 (premiere version reellement utilisable de java, judicieusement nommée java 2 du coup)
      toujours du java 2 = java 1.3, 1.4
      java5 = java 1.5 => evolution du langage etc. justifiant un changement version majeur.


      Si ça justifie tellement un changement de version majeur, pourquoi n'est-ce pas gardé ?
      Il aurait fallut dans ce cas avoir
      java 1
      java 1.2 = 2
      java 2.1 et 2.2 (par ex, pour le 1.3 et 1.4)
      java 5
      mais avec leur 2 = [1.2 .. 1.4] et 5 = 1.5 ça veut plus rien dire je trouve...

      Sinon, je suis partisan du mois.annee pour les projets tres long terme (histoire de savoir quand ils sont sortis, ce qui est plus pertinent comme info, genre pour une distrib)

      tiens, ça me fait penser à un truc qui commence par [kux] finisant par u et avec un truc imcompréhensible au milieu ;-)
      au contraire je trouve que ça ne représente pas grand chose...
      Ce qui est important est plus l'avancement du projet (par rapport aux objectifs) que la date à laquelle ça sort.

      pourquoi un mineur inférieur à 10 ?
      • [^] # Re: java

        Posté par  . Évalué à 3.

        java2 et java5 sont les noms marketings
        1.x sont les noms techniques.
        Ca se tient en fait, les decideurs n'ont que 2 numeros a retenir, les techos ont leur 1.x.y_release, tout le monde est content.

        Ce qui est important est plus l'avancement du projet (par rapport aux objectifs) que la date à laquelle ça sort.
        bah, ca se discute. Pour une distrib', mandrake 10.2, suse 9, fc4 par exemple ne me parlent absolument pas, je sais pas de quand ca date.
        Mandriva 2006, ubuntu 5.10, la je sais precisement quand c'est sorti et je peux imaginer ce qu'il ya dedans.

        pourquoi un mineur inférieur à 10 ?

        psychologiquement, la suivant de 2.9, c'est 3.0.
        Dans mon esprit tout du moins, x.y s'assimile a x,y et du coup 2.10=2.1 et donc 2.9>2.10

        Apres, ca se discute hein, tout ca c'est mon avis a moi que j'ai (et que je partage) et qui n'est pas forcement pertinent (cf mon avis sur la com'/marketing dans le journal de timaniac) ;-)
        • [^] # Re: java

          Posté par  . Évalué à 2.

          Et quand ils arriveront à la 2.2 et la 2.5 ils feront comment pour se comprendre les marketteux et les techos?
          • [^] # Re: java

            Posté par  . Évalué à 3.

            tu sais, avec 5 versions en 13 ans, ya encore de la marge pour changer de notation.
            Voire meme ne pas arriver jusqu'a la version 2.2 :-)
            • [^] # Re: java

              Posté par  . Évalué à 5.

              effectivement, c'est bien connu le java c'est lent...
              ---->[]
    • [^] # Re: java

      Posté par  . Évalué à 0.

      et java 6 !!!! qui ne saurait tarder et est donc la version 1.6 de java qui a pour nom de projet ( si je me souviens bien ) daulphin.
    • [^] # Re: java

      Posté par  . Évalué à 3.

      Juste parce que je n'aime pas trop le raccourci induit par l'utilisation du signe égal, je développe un peu ton explication :

      D'un côté il y a le _langage_ Java, de l'autre les outils : jdk/sdk (development kit), jre (runtime environment).

      1. Dénomination « Java ».

      Le langage Java a été défini dans The Java Language Specification.
      Le « 1 » n'est jamais donné avant la sortie du « 2 », il n'est donné que pour le différencier, a posteriori.

      Les jdk/jre qui permettent d'utiliser ce langage sont les versions 1.0.x et 1.1.x (les 1.1x diffèrent dans l'api standard, notamment la gestion des évènements dans les interfaces utilisateur).

      2. Dénomination « Java 2 ».

      Il n'y a en fait pas eu beaucoup de modifications au langage lui-même, mais l'api standard a intégré Swing et le modèle sand-box des applets/applications a changé (avant : applet signée ou pas, après : + gestionnaire de sécurité avec des droits bien découpés (policy...)).

      Les sdk/jre correspondants sont les 1.2.x, 1.3.x et 1.4.x. Entre 1.2 et 1.3, des modifications de JVM. Entre 1.3 et 1.4, beaucoup de nouvelles api standards (regexp, log, xml...).

      On peut aussi noter l'apparition du mot-clef assert dans le 1.4 (avec la possibilité de l'activer/le désactiver par package).

      3. Dénomination « Java 5 ».

      Grosses modifications du langage : génériques, énumérations, autoboxing, annotations, nouveau for, import static...

      sdk/jre : 1.5.x

      Conclusion

      En fait, comme tu le dis, on peut penser que le 2 du Java 2, c'était surtout pour faire comprendre que les outils étaient débarassés des problèmes de jeunesse des précédentes versions et aussi un pour dire que le langage était stable (cf. le gros décalage d'api entre 1.0 - 1.1 (awt) et 1.1 - 1.2 (Swing)).
  • # Borne

    Posté par  . Évalué à 6.


    chaque digit dans la version mineur représente une milestone (désolé je voyais pas trop comment le traduire à part par "étape importante" mais personne aurait compris ;-) ).


    Borne routière en pierre.
  • # TeX

    Posté par  . Évalué à 2.

    Il y a aussi TeX qui utilise un schéma de numérotation original: il tend vers pi.
    Encore une blague de mathématicien/informaticien, sacré Donald va! ;)

    Pour d'autres inspirations:
    http://en.wikipedia.org/wiki/Version
    • [^] # Re: TeX

      Posté par  (site web personnel) . Évalué à 2.

      Et c'est pas metafont qui tend vers e ? (la base du logarithme neperien)
    • [^] # Re: TeX

      Posté par  (site web personnel) . Évalué à -1.

      A ma connaissance, il tend vers e : logarithme népérien de 2 !

      Je pense que la numérotation de pugs pour le perl6 est un clin d'oeil a Donald Knuth.
      • [^] # Re: TeX

        Posté par  . Évalué à 4.

        e = ln2 ? Tu as appris où les maths ?
        • [^] # Re: TeX

          Posté par  (site web personnel) . Évalué à 2.

          Un p'tit coup de fatigue... et un post un peu rapide avant la scéance des bébés nageurs ;-)
    • [^] # Re: TeX

      Posté par  (site web personnel) . Évalué à 3.

      Et comme Knuth est le seul à avoir le droit de modifier l'original de TeX, le jour de sa mort, TeX sera figé à tout jamais, et son numéro de version sera $\pi$
  • # Simple

    Posté par  (site web personnel) . Évalué à 9.

    Comme beaucoup de monde je pense :

    0.0 pré alpha

    Et ensuite... pas de suite.
  • # One, two, three

    Posté par  (site web personnel, Mastodon) . Évalué à 4.

    Les numéros devraient, comme c'est souvent le cas, informer l'utilisateur sur la compatibilité. Truc 2.0 sauvera probablement dans un format que Truc 1.0 ne pourra pas lire. Mais Truc 2.2 devrait sauver dans un format -toujours le même- que 2.0 pourra lire.

    Souvent également, Z n'est utilisé que pour du bugfix, n'apportant aucune nouveauté au logiciel.

    La gelée de coings est une chose à ne pas avaler de travers.

  • # Relation d'ordre

    Posté par  . Évalué à 6.

    C'est clair qu'il n'y a pas de standard sur les numérotations de versions et que chacun y met un peu ce qu'il veut.

    Mais y'a quand même une convention, qui est importante pour les distrib' et les packageurs, sur la façon dont 2 numéros de version se comparent. Ceci parceque les système de gestions de paquets doivent pouvoir comparer des versions de façon automatique, pour savoir qu'est-ce qui est mise-à-jour de quoi.

    En gros, c'est des nombres qu'on classe, et non des chiffres, et ils doivent être séparés par des points, avec le plus significatif à gauche et le moins significatif à droite.

    C'est à dire que la version 2.11 n'est pas une révision ultra mineure de la 2.1, mais bien la révision mineure qui suit la 2.10, et précède la 2.12. Pour faire une ultra mineure de la 2.1, bah tu l'appelles 2.1.1 (ou éventuellement "2.1a" : les lettres en suffixe, c'est comme un niveau de numérotation ultra mineur supplémentaire).

    De même, la mineure qui vient après 2.9 est 2.10 : et pour ceux qui trouvent ça pas joli, ou peut aussi employer 2.09 à la place de 2.9, comme ça l'ordre est visuellement plus clair (enfin perso je vois pas l'intérêt, mais y'a des gens qui sont perdus apparament quand le nombre de chiffres change dans un nombre... allez comprendre).

    Une autre mauvaise idée, c'est d'utiliser des dates avec leurs nombres dans l'ordre de la langue, genre "mois.année" : le passage de la 12.2005 à la 01.2006 a peu de chances d'être compris des système de paquets. Et c'est bien sûr pire si tu rajoutes le jour là dedans. Bref, dans ce cas, on doit employer : "année.mois(.jour)" (le plus significatif d'abord, une fois encore).

    Un autre truc à éviter qu'on voit de temps en temps, c'est l'utilisation d'un nombre ultra mineur pour indiquer des préversions. Genre on prépare un release 1.2, mais on appelle les snapshots CVS préalables 1.2.20051205. Bon bah là encore, ça trompe tout le monde, et il faut dans ce cas plutôt employer un suffix distinct qui montre bien qu'on se situe en dessous de la version visée, du style "1.2_alpha20051205" ou "1.2_pre20051205", etc.

    Voilà, si tu fais gaffe à ça, tu feras plaisir aux éventuels futurs mainteneurs de ton logiciel dans les distribs, et tu leur épargneras la peine de ruser pour transformer tes versions en des trucs utilisables.
  • # mes numeros de versions à moi

    Posté par  (site web personnel, Mastodon) . Évalué à 9.

    voici comment j'utilise les numeros de versions. ils sont de la forme X.Y.Z

    X : numéro de version majeure. Incrementé quand il casse la compatibilité avec la version majeure précedente (au niveau document, plugins etc..), ou alors quand il y a d'énormes changements (nouvelle architecture, refonte, beaucoup plus de fonctionnalités ...). En fait, on pourrait dire que X correspond à une branche majeure (au niveau CVS, subversion..)

    Y : numéro de version "features". Il est incrémenté quand de nouvelles fonctionnalités significatives sont ajoutées.

    Z: numéro de version "bug" . il est incrémenté quand il y a eu simplement des bugs corrigés (et eventuellement des fonctionnalités mineures, des petites améliorations peu significatives)


    et on peut ajouter "alpha", "beta", ou "RC" qui correspondent à des étapes de développement d'une version X.0 ou X.Y (ça n'a pas vraiment de sens pour X.Y.Z sauf pour les projets énormes)
  • # Le plus magnifique exemple (troll volontaire)

    Posté par  . Évalué à 3.

    L'exemple le plus débile en la matière est gaim

    Preuve:

    http://gaim.sourceforge.net/ChangeLog

    Ils changent de numéro de version majeure dès qu'ils corrigent des bugs...
  • # Ubuntu

    Posté par  (site web personnel) . Évalué à 2.

    Il faut souligner la versionistation très spéciale de ubuntu :
    nom + dizaine d'annee.mois
    En pratique, la version sortie en octobre 2005 s'appelle breezy 05.10
    La prochaîne s'appelera ****** 06.04 (Les noms n'ont pas de rapport avec la version, voire pas de rapport avec le logiciel d'ailleurs ;)

    C'est la première fois que je voyais ce système de notation et j'avoue ne pas l'avoir compris tout de suite (une page de doc m'a sortir rapidement de mon ingorance).

    J'aime ce système car il est cliar, ert permet de situer rapidement une version dans le temps. (Sur des énormes projets, c'est important)

    Et pour faire dans le pur troll, java et Debian se rapproche fortement : les nouvelles versiosn tardetn à sortir, et les numéros ne servent pas ...
  • # La palme

    Posté par  (site web personnel) . Évalué à 2.

    La palme de la numérotation de version revient à mon avis à l'équipe de SmartEiffel (autrefois SmallEiffel) http://smarteiffel.loria.fr qui donnait des numéros de version négatif, chaque nouvelle version se rapprochant de plus en plus de 0.

    Depuis ils sont revenus à une numérotation plus classique (la 2.2 devrait bientôt sortir) et franchement je trouve ça un peu triste...
    • [^] # Re: La palme

      Posté par  . Évalué à 4.

      > La palme de la numérotation de version revient à mon avis à l'équipe
      > de SmartEiffel (autrefois SmallEiffel) http://smarteiffel.loria.fr qui
      > donnait des numéros de version négatif

      Et c'est comme ça qu'on avait des paquets Debian qui s'appellaient "1.X.Y", où le "1" n'indiquait rien, le "X" était une numérotation arbitraire propre à Debian (et la seule utile en fait pour comparer les versions de paquets), et le "Y" était la valeur absolue de la numérotation officielle, ajoutée pour information. Vraiment pratique, et pour les packageurs, et pour les utilisateurs...

      > Depuis ils sont revenus à une numérotation plus classique (la 2.2
      > devrait bientôt sortir) et franchement je trouve ça un peu triste...

      C'était à mon avis une joke de geek dont il est bon de s'être finalement aperçu qu'elle devenait lourde. Franchement, je pense pas que ça soit la morosité ambiante ou bien l'arrivée de rabats-joie dans l'équipe qui ait provoqué ce retour à une numérotation classique, mais plutôt bel et bien le bon sens.

      Faut pas oublier que le numéros de version, c'est un élément de communication entre les dévelopeurs et le reste du monde. Et pour bien communiquer, bah faut que tout le monde utilise à peu prêt le même langage... S'inventer sa propre numérotation qui prend à contrepied tous les usages, c'est à peu prêt aussi malin que d'écrire sa seule documentation en Klingon.
    • [^] # Re: La palme

      Posté par  . Évalué à 3.

      Moi, je trouve que la palme revient plutôt à mplayer:
      Après avoir eu un système de numérotation assez classique de 0.1 à 0.9, ils sortent depuis plus de deux ans des versions baptisées 1.0pre.. (on en est à 1.0pre7try2 !).
      On dirait qu'ils ont tellement peur de nommer une version "1.0" qu'ils ont adopté une numérotation qui tend indéfiniment vers 1.0 sans jamais l'atteindre !
      J'attends avec impatience la 1.0pre22try3fix12patch23 aux alentours de 2010 ;)
      • [^] # Re: La palme

        Posté par  . Évalué à 1.

        Ça s'est passé comme ça avec linux, avant la 1.0 :)
        En mars 92, c'était passé de 0.12 directement à 0.95. Du coup, il y a eu des 0.99 Patch Level A, puis 0.99 Patch Level 15B, etc. jusqu'au Patch Level 15Z, et le Patch 16 s'est transformé en 1.0 en mars 94 :).
        (Source : la Bible... euh pardon, l'autobiographie de Linus "Il était une fois Linux")
  • # C'est un gros problème ça

    Posté par  (site web personnel) . Évalué à 4.

    C'est la foire à la saucisse, chacun fait au feeling. Le pire est selon moi le noyau Linux. Déjà trois chiffre, il fallait suivre, mais là y'en a quatre ... pour la version de base ! Après, il y a des "mm", "vanilla", "mdk" pour Mandrake, avec des suffixes "i586" pour les archictures sous Debian, etc. Moi j'ai un paquet "linux-image-2.6.12-10-386" avec la version "2.6.12-10.24" :-) Il faut un BAC+2 pour lire la version du noyau. Pourquoi on dirait pas "Linux 6 et des brouettes" ??? Ben, nan chacun veut son suffixe personnalité.

    Bon, sinon, pour les logiciels, ça donne : 0.0, 0.1, ... après ça part dans tous les sens : 0.1.1 ou 0.2 selon mon humeur. Puis des fois, hop, ça saute en 0.5. Et très rarement, ça passe en 1.0.

    C'est idiot car la plupart du temps, des programmes tout à fait corrects ont des numéros de version < 1.0. Je pense que, comme moi, les développeurs cherchent la perfection ultime. Mais ceci a un effet pervers : "version 0.86.6pre6", hou là, ça a l'air instable ça ...

    Je ne sais pas si ça a été dit (j'ai lu les autres commentaires en diagonale), mais il existe aussi le très bon numéro de version "année-mois-jour". C'est plutôt neutre et très parlant ! WINE l'a utilisé pendant longtemps.

    Avec SubVersion, on pourrait utiliser le numéro de commit :-) "Utilisez la version 340349 qui est un poil plus performante que la 340176 mais moins ergonomique que la 340348".

    ---

    Pour finir ce bref tour d'horizon, j'apprécie le système Ubuntu et Gentoo qui parle de lui même => 5.10, version d'octobre (10ème mois) de 2005 ! J'aime aussi les "milestones" qui marquent une étape dans l'avancement du projet. J'avais vu ça dans le projet Gobelins, et l'idée m'a bien plu (en plus, Trac aide beaucoup pour cela) :
    http://projects.nekeme.net/projects/gobelins/roadmap

    Haypo

Suivre le flux des commentaires

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