Évolution de la version d'un logiciel

Par Vincent Robert, . Lien permanent

Hadrien a posté un billet très intéressant présentant son avis sur l'évolution à donner aux numéros de versions d'un logiciel au cours de sa vie.

Je ne suis pas complètement d'accord avec ses propositions, je vais donc exposer les miennes maintenant.

Tout d'abord, un point rapide : oui je sais, je n'ai pas encore mis en ligne la partie 2 de mon précédent article. Il est en cours d'écriture, considérez celui-ci comme un intermède.

Bon revenons à notre problème. Hadrien souhaite avoir une différence forte entre la numérotation des ajouts de fonctionnalités et les corrections de bugs. Alors qu'auparavant, il utilisait un nombre à deux chiffres pour représenter les deux, il semble s'orienter maintenant vers une séparation plus forte par un point. C'est à dire que pour désigner la 5e version avec la 4e correction, il passe de 1.54 à 1.5.4.

C'est une décision qui semble être suivi par de nombreux logiciels et je me sens concerné car c'est le choix de numérotation que j'ai adopté dans ChuWiki, aujourd'hui en version 1.3.1.

Mais voilà, il se trouve que depuis quelques temps, je suis en train de remettre en cause cette numérotation. Mon problème vient du premier chiffre de version : 1. Comment se chiffre a-t-il été choisi ? Initialement bien-sûr, lorsque le logiciel a été rendu publique pour la 1re fois en 1.0. (Je n'approuve vraiment pas les projets qui osent rendre publique une version 0.X, 1.0 signifie qu'il s'agit de la 1re version où le logiciel fait ce qu'il est censé faire initialement. Mais c'est un autre sujet que je pourrais développer une autre fois.)

Donc je viens de rendre publique une 1.0 dont je suis très fier. Elle ne fait pas grand chose mais elle le fait (non pas forcément bien non plus mais tant pis). Si c'est vraiment une 1.0, il y a des chances que je commence par effectuer des corrections. Ouis mais voilà, en plus de ces corrections, j'ajoute aussi quelques fonctionnalités mineures. Et hop, rapidement une 1.1 se présente. Pourquoi 1.1 ? Et bien je n'ai vraiment pas fait suffisament de modifications pour oser sortir une 2.0. J'augmente donc la version « mineure » pour signifier qu'il s'agit toujours de la version 1 mais avec quelques corrections.

La spirale démarre alors. Je vais finalement ajouter petit à petit (oui j'ai pas le temps !) des fonctionnalités et à chaque fois augmenter le numéro « mineure » de version. Aujourd'hui, ChuWiki est en version 1.3. Mais voilà, récemment je fais une petite correction sur le thème de la 1.3. Oh je n'ai pas modifié tant que ça la version, rien ne justifie une 1.4. Suivant la même réflexion qu'Hadrien, je crée une 1.3.1.

Tout cela semblerait très logique si je ne commençait pas à me poser des questions stupides comme : mais finalement, qu'est-ce qui justifierait un passage en 2.0 ? Hadrien mentionne une « évolution suffisamment significative ». Soit. Qu'est-ce qu'une évolution significative ? La nouvelle version guérit le cancer ? Ah non rien à voir... Ah mais oui ! Elle a été en partie réécrite ! Oui d'accord... Mais à quel point ? Parce que finalement, c'est ce que l'on fait tous les jours quand on fait évoluer une application que d'en réécrire des parties. Elles sont juste plus ou moins grandes.

« Où est-ce qu'il veut en venir ? », te demandes-tu, ô fidèle lecteur.

Lorsqu'on écrit un logiciel, il est normal qu'on le fasse évoluer, qu'on lui ajoute des fonctionnalités, qu'on change son architecture, qu'on corrige des bugs. Mais le plus important est finalement ce qu'on va livrer à notre utilisateur. Et dans le monde du logiciel, il n'y a que deux notions, soit vous avez modifié le logiciel, soit vous l'avez corrigé. Bingo, il n'y a que deux versions à maintenir ! La majeure : représentant le niveau de fonctionnalité et la mineure : représentant les corrections.

En se basant sur ce principe, ChuWiki n'est pas en version 1.3.1 mais en version... 3.1 ! Et oui, vous ne le saviez pas mais ChuWiki 3 est sorti ! C'est finalement bien plus compréhensible pour l'utilisateur. Et puis je n'ai pas à me poser toutes ces questions existencielles quand je me demande de quoi serait composé un « ChuWiki 2.0 ». J'assume enfin qu'il n'y aura jamais de version 2.0, celle qui guérit le cancer et éradique la famine dans le monde. L'évolution de mon logiciel n'est déterminé que par les ajouts que j'y fait et son histoire suit son cours.

Ce choix peut paraitre exagéré, mais il s'agit finalement d'assumer l'évolution de son logiciel. En effet, la version 3 de mon ChuWiki est maintenant bien loin de la version 1. Plus de fonctionnalités, pas vraiment compatibles, ses versions sont finalement plus justifiées que je ne le pensais initialement.

D'autres que moi ont fait ce constat. Vous avez sans aucun doute déjà entendu parler de l'histoire de cette petite plateforme appellée Java qui a évolué en version 1.0, 1.1, 1.2 (ou Java 2 comme certains « osaient » l'appeller), 1.3, 1.4 et finalement 5 puis 6. Java 6. Sun a enfin compris que les modifications apportées à son logiciel justifiaient largement un changement de version majeure. Et surtout que ce n'était pas la peine de courir derrière ce rêve qu'était Java 2.0. Je suis sûr qu'aujourd'hui, Java 6 est allé bien au-delà, pas forcément dans la même direction mais finalement dans une direction plus logique et plus tournée vers l'utilisateur.

Assumez vos versions ! Ne courrez pas après un rêve qui ne réalisera jamais ! À mort le 2.0 ! Vive le 3 (4, 5, 6) !

Haut de page