Règle #1 pour livrer du logiciel : définir un numéro de version !
Quel numéro choisir ?
Le must du must est d’utiliser et de suivre le Semantic versioning. C’est-à-dire, d’utiliser trois chiffres :
MAJOR.MINOR.PATCH
- MAJOR : incompatible API / ABI changes,
- MINOR : functionality added in a backwards-compatible manner
- PATCH : backwards-compatible bug fixes
Ce qui implique que si je trouve un bug dans ma bibliothèque v3.1.2, que je corrige ce bug, je vais publier ce correctif dans une nouvelle v3.1.3 uniquement si je n’ai pas fait de changements bloquants (c’est-à-dire que mon soft qui tournait avec la v3.1.2 de cette bibliothèque pourra utiliser v3.1.3 sans rien changer). Si mon correctif implique des changements bloquants (pas de bol), il faut changer le numéro de version majeur (v4.0.0), eh oui.
Trouver le numéro de version
Il n’y a rien de pire que de faire tourner un soft et de ne pas savoir quelle est la version qui tourne. Avoir un numéro de version c’est bien beau, mais il faut aussi l’afficher quelque part :
- Au démarrage du soft
- Dans un log
- Sur l’IHM
- Dans l’API
N’importe où, mais quelque part !
Modifier le numéro de version
Un autre corollaire de cette règle #1, c’est qu’il faut pouvoir modifier facilement ce numéro de version. Il doit être défini en un unique endroit. Par exemple :
- Qt : Le fichier
.qmake.confest inclue au début de chaque fichier .pro et .pri, c’est le candidat idéal - PHP / Symfony :
app/config/config.yml
Selon son architecture de développement, on peut aussi s’assurer qu’un tag Git vient préalablement mettre à jour le numéro de version dans le code.
