Début de semaine, tour de table obligatoire pour savoir ce qu’on a fait, et ce qu’on va faire. On commence à être excités, la nouvelle version de notre soft est en cours de préparation. Des fonctionnalités intéressantes sont ajoutées à une vitesse croissante, et les bugs qui vont avec… On en parle, on décide, tout va pour le mieux.
Et puis, coup de théâtre de notre DG ! Cette version ne sera pas la 3.5, on va directement passer à la 4.0 !
Applaudissements de toutes parts ! Les bouquets de roses volent ! Notre DG s’en va, magnifique, alors que le rideau retombe doucement sur notre salle de réunion.
Mais en coulisse, on se met à en discuter : Pourquoi 4.0 ? Qu’est-ce qui peut bien les avoir poussés à changer de version majeure ?
Les réponses nous reviendront au cours de la semaine, fragmentées et de sources différentes : parce que… ce qu’on a fait, c’est suffisant pour le justifier… nos clients attendent du changement…
On se fait vite à l’idée que ce changement de version n’aura absolument aucun impact pour nous, mais qu’on pourra montrer, avec force publicités, que plein de choses arrivent du côté de chez nous, même si ce n’est pas vraiment le cas…
Pour avoir un peu bossé avec et pour des projets open source, la politique de nommage de version y est souvent beaucoup plus claire : on ne change de version majeure qu’en cas de très grosse modification, du genre qui casse la rétrocompatibilité.
Évidemment, ça n’a jamais été le cas pour nous. On a dû garder la rétrocompatibilité avec les anciens modèles d’application. On a dû garder un tas de fonctionnalités toutes plus inutiles les unes que les autres. On a dû garder plein de choses qu’un jour, un client nous a demandé, qu’on a codées, et que plus personne n’utilise, le client concerné y compris.
Près d’un an plus tard, on a sorti plusieurs versions mineures, avec de nouvelles fonctionnalités dans tous les coins, sans jamais remettre en cause tout ce qui devrait être mis au placard. On va probablement garder cette maudite rétrocompatibilité encore bien longtemps, et les versions suivantes vont garder leurs documents de mise à jour des modèles d’applications.
Ah ! Oui ! Je n’en avais pas parlé ? Avec chaque version, on a quand même besoin de fournir des documents pour expliquer comment passer d’une version à une autre… Va comprendre !
Niveau rétro-compatibilité, on aura vu mieux.