The Rules of Life

Règle #1 – Numéro de version

Publié dans Développement | Marqué avec , ,
Share

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.conf est 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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *