Puis je suis tombé sur ce billet d'Hadrien qui décrit sa façon de donner une version aux logiciels. J'ai adopté cette méthode pour mes développements.

Cette méthode utilise 3 nombres : x, y et z. x est la version majeure, y la version mineure et z indique une nouvelle version corrigeant un bug. Ainsi la première version d'un de mes logiciels est la version 1.0. Si j'apporte une amélioration la version devient 1.1, la version suivante sera la version 1.2. Et la version qui corrigera un bug sera la version 1.2.1. C'est simple non ?

Un billet de Vincent répondant à Hadrien montre que cette méthode a ses limites : qu'est-ce qu'une version majeure ? Pour moi cela correspond à une profonde restructuration du code, voir à une réécriture totale du logiciel. Oui mais, est-ce que ça arrive souvent ? À partir de quel point une modification mineure devient une modification majeure ? Quand plus de 30% des lignes du code ont été modifiées ?

Pour ma part, je continue à utiliser les numérotations en x.y.z car malgré ses limites elle décrit bien les changements dans le code. Quitte à ne jamais sortir de version 2 de mes logiciels.

On pourrait aussi utiliser un seul nombre entier comme numéro de version. La première version serait la 1, la version 2 apporterait une nouvelle fonctionnalité ... et la version 7 corrigerait un bug. Cette méthode a un énorme défaut, elle ne rend pas compte de l'avancement d'un projet : à quoi correspond une version 752 ? À la 752ème correction de bug ou au 752ème ajout de fonctionnalité ?

Le plus grand problème est qu'il n'y a pas de standard pour ces numérotations. Comment l'utilisateur lit ses numéros de version ? Peut-être faudrait-il ajouter à chaque logiciel une explication du numéro de version propre au logiciel.