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 ?
Journal numérotation (version) d'application
7
déc.
2005
# java
Posté par serge_kara . Évalué à 2.
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 CrEv (site web personnel) . Évalué à 3.
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...
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 serge_kara . Évalué à 3.
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 golum . Évalué à 2.
[^] # Re: java
Posté par serge_kara . Évalué à 3.
Voire meme ne pas arriver jusqu'a la version 2.2 :-)
[^] # Re: java
Posté par tuxyl . Évalué à 5.
---->[]
[^] # Re: java
Posté par Nahuel . Évalué à 0.
[^] # Re: java
Posté par Sylvain Sauvage . Évalué à 3.
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 DocteurCosmos . Évalué à 6.
Borne routière en pierre.
[^] # Re: Borne
Posté par liberforce (site web personnel) . Évalué à 3.
# TeX
Posté par Sebastien Binet . Évalué à 2.
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.
[^] # Re: TeX
Posté par Sytoka Modon (site web personnel) . Évalué à -1.
Je pense que la numérotation de pugs pour le perl6 est un clin d'oeil a Donald Knuth.
[^] # Re: TeX
Posté par Moonz . Évalué à 4.
[^] # Re: TeX
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: TeX
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
# Simple
Posté par pyrollo (site web personnel) . Évalué à 9.
0.0 pré alpha
Et ensuite... pas de suite.
# One, two, three
Posté par Lol Zimmerli (site web personnel, Mastodon) . Évalué à 4.
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 tgl . Évalué à 6.
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 Laurent J (site web personnel, Mastodon) . Évalué à 9.
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 blenderman . Évalué à 3.
Preuve:
http://gaim.sourceforge.net/ChangeLog
Ils changent de numéro de version majeure dès qu'ils corrigent des bugs...
# Ubuntu
Posté par chtitux (site web personnel) . Évalué à 2.
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 jcs (site web personnel) . Évalué à 2.
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 tgl . Évalué à 4.
> 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 netsurfeur . Évalué à 3.
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 xumelc . Évalué à 1.
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 Victor STINNER (site web personnel) . Évalué à 4.
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.