Quand on parle d’espèces menacées, on pense facilement au guépard ou au thon rouge. Mais je suis prêt à parier que vous ne pensez pas aux numéros de version.
Et pourtant, silencieusement, ces monuments de l’industrie logicielle sont en train de disparaître du paysage. Et cette évolution a des choses à nous apprendre.
Le numéro de version, sa vie, son œuvre
Dans leur définition la plus large possible, les numéros de version sont omniprésents dans le monde logiciel. Au plus bas niveau on trouve des numéros de build ou des révisions de VCS, on a ensuite des numéros de version privés (alpha, beta et autres releases internes) jusqu’aux numéros de version publics.
Nous les utilisons fondamentalement pour la même chose : mettre un nom sur un ensemble de changements ou de fonctionnalités, ce qui est indispensable pour communiquer, que ce soit entre développeurs, dans des relations client/support ou des contrats de licence.
Si le concept de numéro de révision a disparu dans les systèmes de gestion de version distribués, il y a toujours des étiquettes associées aux modifications (e.g. le hashtag d’un commit dans git) parce que nous développeurs en avons besoin pour travailler au quotidien.
Qu’en est-il d’un numéro de version public, celui qui identifie votre logiciel auprès des clients et utilisateurs ? C’est ce que nous allons voir...
Au commencement
Avec la dématérialisation du logiciel, on tend à oublier qu’à une certaine époque, livrer une version était un processus long et coûteux. Les moins de 20 ans ne connaîtront jamais l’expérience unique d’installer une version d’Office occupant 36 disquettes...
Crédit photo : Josh Gallaway (CC BY-NC-SA 2.0)Les numéros de version sont alors associés à une réalité matérielle qui contraint le travail des développeurs et force à regrouper les changements par des lots bien définis et de taille suffisante pour justifier la sortie d’une nouvelle version.
A mesure que la distribution du logiciel s’est simplifiée, il est resté d’autres contraintes techniques : validation fonctionnelle, tests de charge, procédure de déploiement ou de mise à niveau...
Par ailleurs, au niveau commercial on trouve l’accord de licence. Les versions sont alors un moyen de vendre un service particulier, l’utilisateur devant repayer pour obtenir la version suivante et les nouvelles fonctionnalités qu’elle apporte.
wwwho needs version numbers anyway ?
L’apparition des applications web a fait exploser la contrainte de distribution. Dans un modèle devenu centralisé, il est malaisé de maintenir plusieurs versions en parallèle, versions qui doivent être hébergées séparément. Il est bien plus simple d’offrir la même pour tous les utilisateurs.
Les modèles de licences évoluent du paiement à l’achat (adapté à un logiciel considéré comme un produit vendu sur un support) vers le paiement à l’utilisation (adapté à un logiciel considéré comme un service).
Un certain nombre d’application web ont donc simplement abandonné le concept de numéro de version public. Vous ne savez pas quelle version de Gmail vous utilisez et il est probable que vous ne savez pas non plus avec quelle version de l’application web de votre banque vous passez vos virements.
Le cas Google Chrome
Google a poussé l’expérience plus loin. Profitant du fait que les utilisateurs de son navigateur Chrome étaient par définition connectés à Internet, ce dernier se met à jour automatiquement, silencieusement et le numéro de version n’est pas public.
Cette modification a fait des vagues, de nombreux utilisateurs ayant le sentiment de perdre le contrôle du logiciel, d’autant plus que traditionnellement le développement web s’effectuait vis à vis de versions particulières de chaque navigateur, du fait d’importantes différences dans le support des standards.
Le lead developer de Google Chrome, Ben Goodger, s’en est expliqué ainsi :
The Chrome autoupdater works quietly in the background, never notifying you. If there's an update, it'll download it and prepare it so that the next time you start the browser it's the latest version. Sort of like how the next time you load GMail it's the latest version.
Depuis, le navigateur concurrent Firefox a lui-aussi adopté un système similaire (cependant plus visible) même si les numéros de versions publics ont été conservés.
Le raisonnement à l’origine de ce choix de design est assez simple : aussi bien pour des raisons de sécurité que de fonctionnalités, il est hautement désirable que les utilisateurs disposent toujours de la toute dernière version. Dès lors, est-il vraiment pertinent de leur laisser le choix d’utiliser une version particulière ? Et une fois acté qu’on ne leur laissait pas ce choix, pourquoi rendre visible le processus de mise à jour ?
L’autre point intéressant soulevé par Ben Goodger est le suivant et c’est là que je voulais en venir :
Autoupdate is one of Chrome's killer features. It is magical because it continuously updates an entire development platform invisibly, frequently. Supporting it has driven how we structure our development processes.
Impact sur le développement
Les politiques de versions sont toujours intimement liées à la façon de développement, dans un sens ou dans l’autre.
Pour Chrome, il s'agissait d'un cas assez extrême où la construction entière de l'application s'est faite sur le postulat que l'évolution du logiciel serait continue. Mais ce type de choix n'est pas toujours possible.
Lorsque la politique de versions n’est pas librement choisie, elle découle souvent du coût et de la vélocité de la mise en production. Plus il est “douloureux” de mettre en production, plus les versions seront espacées et rigides.
Un tel fonctionnement impose de recourir à des features branches (ou des artifices comme le shelve de Subversion ou le stash de git) et conduit à des merges souvent d’autant plus coûteux que les développements longs divergent du trunk.
Ces problèmes ne sont pas nouveaux et ont conduit à la création d’outils et de méthodes pour rendre la mise en production plus simple. Intégration continue, “Feature Flipping” et outils de migration de schéma de bases de données permettent de rendre la mise en production rapide, simple et fiable.
On peut prendre comme exemple les pratiques de déploiement du site américain Etsy, dont le directeur technique Mike Brittain a fait une présentation en janvier dernier intitulée “Continuous Deployment : the Dirty Details” :
Etsy déploie jusqu'à près de 80 fois par jour en production
Dans un tel contexte, tout le monde travaille sur une seule et unique branche et on déploie en continu des fonctionnalités non terminées mais pas forcément activées ou visibles.
On arrive donc à un point où, s’il fallait marquer d’une version chaque changement du logiciel, il y aurait de l’ordre de 15000 versions par an pour Etsy ! La notion de version publique perd donc ici tout son sens.
Et après ?
La généralisation des applications web et du SaaS, associés à des pratiques de développement qui tendent de plus en plus vers le déploiement en continu vont réduire à terme les numéros de version à leur portion congrue.
Ils resteront utiles voire indispensables partout où il y a un besoin impératif d’être d’accord sur un ensemble de fonctionnalité précis, comme par exemple pour des APIs ou des composants.
Mais il est clair que pour l’utilisateur final, le numéro de version ne sera bientôt plus qu’une relique du passé informatique.
Et vous, quelle est la politique de version pour votre produit ?
Christophe est consultant Arolla, avec un goût particulier à la fois pour le développement web coté serveur en Java et coté client en HTML5, le tout en TDD. Il est aussi difficile à battre à la pétanque. Retrouvez Christophe sur Twitter : @christopheml et le blog Arolla sur @arollafr
Développeur JEE et passionné d'informatique
1 comment for “Les numéros de version vont-ils disparaître ?”