Je me pose depuis longtemps la question de savoir comment établir un schéma, une convention, une sorte de norme pour la numérotation des versions des développements que je fais ou auxquels je participe. Dans Dotclear — la dernière version publiée est la 2.2.3, là où mon activité de développement est la plus dense, nous avons l’habitude de garder le 2 initial pour indiquer que c’est la deuxième version majeure de ce logiciel[1], d’utiliser le nombre qui suit pour indiquer les changements majeurs de fonctionnalités et enfin le dernier pour indiquer les révisions successives qui ont lieu entre deux versions majeures.
Personnellement pour mes développements personnels, j’utilise une forme similaire, à savoir la forme version-majeure.version-mineure.micro-version, où la version majeure est positionnée à 0 tant que toutes les fonctionnalités prévues n’ont pas été intégrées, pour passer ensuite à 1 une fois que c’est fait et parfois à 2 et au-delà lorsqu’il m’arrive de réecrire le code pour améliorer sa factorisation, son extensibilité et son optimisation. Les versions mineures démarrent à 0 à chaque changement de version majeure pour ensuite s’incrémenter à chaque nouvelle implémentation d’une fonctionnalité. La micro-version me sert pour chaque publication et pour marquer les révisions incluant essentiellement les corrections du code.
C’est un schéma classique, communément utilisé, comme d’ailleurs le précise la page wikipedia correspondante.
D’autres personnes utilisent d’autres manières de numéroter ou d’identifier leurs versions de développement. Je sais qu’au moins un des développeurs de plugin de Dotclear utilise la date comme numéro de version. J’avoue que l’idée m’a séduit au premier abord puis, après réflexion, j’ai trouvé que l’information transportée était beaucoup moins riche, la date seule au lieu des indications de version majeure, mineure et micro. Du coup je conserve l’actuelle.
Certains développeurs, l’équipe de la team Dotclear comprise, utilisent de plus une indication alpha, parfois agrémentée d’un numéro, béta ou RC qui désigne alors une version susceptible de devenir la prochaine version stable. C’est assez fréquent sur les gros projets et, ou lorsqu’on demande l’aide des utilisateurs pour effectuer quelques tests et retours sur une version qu’on s’apprête à diffuser plus largement.
Personnellement j’utilise la mention beta très rarement et exclusivement pour faire faire quelques tests à quelqu’un en vue d’une sortie prochaine d’une version. Pour résumer voilà représenté schématiquement la façon dont je numérote les versions (cliquez sur l’image pour l’afficher à sa taille normale) :
Et vous, vous faites comment ?
Notes
[1] Il y a une confusion entre la version 2 de Dotclear et le 2. utilisé en début de version et nous n’avons jamais vraiment tranché à son sujet. Pour être tout à fait rigoureux nous aurions probablement du commencer par la version 1.0.0 de Dotclear 2, au lieu d’une version 2.0, n’est-ce pas ? Mais les choses étant ainsi, je crois que nous allons continuer longtemps à conserver ce 2 en préfixe. D’ailleurs Dotclear 2 1.0.0 fait autrement plus bizarre que Dotclear 2.0.0 non ? Donc voilà !
1 De JcDenis -
Jusqu’ici j’utilisai une numérotation de version que nous appellerons standard comme celle de Dotclear ou encore PHP: majeur.mineur.microfix. Mais pour diverse raisons, comme par exemple “je suis très brouillons” ou encore “je n’aime pas faire comme tout le monde”, depuis un mois toutes les nouvelles versions de mes plugins utilisent une numérotation par date, c’est à dire la version 2011.04.16 ce qui pour moi est plus pratique, mais qui ne donne aucune indication de l’état du plugin à l’utilisateur, hormis peut-être le fait qu’il n’a pas été mise à jour depuis 10 ans.
En esperant ne pas t’avoir aidé.
2 De Joël -
Il y a la technique consistant à prendre un nombre comme 3.14159265…, à commencer par publier la version 3, et à ajouter une décimale à chaque nouvelle version.
3 De Franck -
JcDenis j’avoue humblement avoir pensé à toi quand je parlais de cette façon d’indiquer les versions de développement. À mon sens, utiliser la date peut porter à confusion, surtout lorsqu’il y a plusieurs branches qui avancent en même temps. C’est du coup moins intuitif, surtout pour celui chargé de maintenir voire de fusionner les travaux de chacun. Fusionner la 2.3, la 2.4 mais pas la 3.0 pour en faire une 2.5, ça va. Si tu utilises des dates, tu es obligé de maintenir quelque part un référentiel rigoureux.
Cela dit de gros projets utilisent les dates pour noter les versions, comme par exemple Ubuntu qui indique l’année et le mois de sortie d’une version stable — nous en sommes à la 11.04, soit celle publiée en avril 2011. Par contre je ne sais pas s’ils conservent le même schéma pour les développement en interne.
Joël j’ai en effet découvert cette façon asymptotique de numéroter les versions dans la page wikipedia que je cite en référence dans mon billet. J’ai lu que π et e étaient souvent utilisés pour ça.
4 De JcDenis -
Franck, effectivement pour ma part je n’utilise jamais plusieurs branches, je suis égoïste et abandonne lâchement les versions précédentes d’un plugin pour suivre le développement du programme principale. (Dotclear)
Dans tous les cas l’identifiant de version pour Dotclear doit au maximum ressembler à qqch comme 0.0.0-xx car la tradition veut qu’on compare avec la fonction PHP version_compare qui est basée sur cette structure ce qui limite un peu le choix déjà.
Tiens il y a aussi le numero de commit sur un svn par exemple. (pas pratique non plus pour les branches :p )
5 De mirovinben -
J’utilise (mais pas tout le temps) le principe du 1.2.3a où a s’incrémente, si besoin, en fonction des corrections de bug mais sans modif des fonctionnalités.
6 De xave -
Mirovinben, tu es un sage. J’en connais qui veulent introduire des fonctionnalités entre x.x.n et x.x.n+1 …
7 De Cunégonde -
Je ne fais pas !
Mais en photo lorsque que je garde plusieurs facettes d’un même raw, je rajoute un tiré et un chiffre pour savoir où j’en suis. Comme pour mes billets qui ont plusieurs fois le même titre.
8 De Franck -
JcDenis certes, mais on pourrait tout à fait utiliser année.mois.jour (éventuellement suivi de -xx) et dans ce cas continuer à utiliser la fonction
version_compare()de PHP ;-)mirovinben ok mais que représentent les nombres que tu utilises ?
xave, on veut des noms !
Cunégonde, je fais idem quand je sors plusieurs versions de développement d’une photo.
9 De mirovinben -
Heu… Ça varie en fonction de la disponibilité de mes neurones, du souvenir des règles à appliquer et de mon humeur du moment. Mais, globalement, les nombres correspondent à ce que tu décris dans ton billet.
Donc : (version-majeure).(version-mineure).(micro-version + x évolution-débogage)
Utile selon moi si envoi de fichiers par mail à d’autres testeurs. Cas pratique avec zip extension Dotclear: mes nombreux échanges avec karpediem pour vérifier le bon comportement de mes widgets “mrvbXxx” dans une configuration multilingue que je n’ai pas sous la main.
N.B. Méthode très mirovinbienne et peu conforme sans doute : je n’ai pratiquement jamais suivi de formation en programmation (il y a très longtemps quelques séances de Basic en cours du soir à l’IUT de Dijon puis une semaine de C en plein mois d’été au bord de la Méditerranée… hum… très intéressant)…
10 De mirovinben -
Je vais revenir au classique (version-majeure).(version-mineure).(micro-version) en m’abstenant d’y ajouter une lettre pas forcément compatible avec certaines fonctions PHP (merci à Moe pour son explication donnée ailleurs).
11 De Franck -
Tiens mirovinben je me demande quel est ton usage de la micro-version si ce n’est pas pour les versions de correction successives ?
12 De mirovinben -
Comme un peu expliqué dans mon commentaire #9, j’avais expérimenté l’ajout de la lettre lors des différentes versions de mes plugins (zippés à l’aide du plugin packager qui reprend le n° de version dans le nom du fichier obtenu) envoyées par mail à Karpediem puisque je n’avais pas à dispo une plate-forme de test multilingue et que je deboguais à tâtons. Cela m’évitait d’incrémenter trop vite la partie “micro-version” des versions intermédiaires suite aux retours de test.
Intéressant dans ce cas, peut-être, mais idiot dans le cas d’une version “publique” supposée stable.
13 De Franck -
Je n’ai pas ce genre de scrupules, je veux dire incrémenter la micro-version à chaque version diffusée, même à fin de test. Après tout cette micro-version est là pour ça et peu importe qu’elle s’incrémente beaucoup je pense.
Cela dit chacun est libre de faire comme bon lui semble, évidemment :-)
Peut-être qu’un petit billet explicatif sur la fonction PHP
version_compare()serait utile ?14 De mirovinben -
“Peut-être qu’un petit billet explicatif sur la fonction PHP version_compare() serait utile ?”
Pourquoi pas en effet… Ça éviterait à d’autres de partir dans des délires à ma façon.
15 De Franck -
mirovinben, à lire ici ;-)
16 De mirovinben -
J’ai vu… (j’ai organisé mon agrégateur pour lire d’abord les nouveaux billets puis les nouveaux commentaires)