L'évolution des bibliothèques logicielles passée au crible
Lorsque les bibliothèques logicielles évoluent, elles introduisent parfois des changements non-rétrocompatibles qui peuvent impacter leurs utilisateurs. Des chercheurs du Laboratoire Bordelais de Recherche en Informatique (LaBRI - CNRS/Bordeaux INP/Université de Bordeaux) et de l'Eindhoven University of Technology ont montré que, bien loin de la croyance populaire, les développeurs sont plutôt disciplinés dans l'évolution de leur bibliothèque. La majorité respecte les bonnes pratiques d'évolution et, même lorsque ce n'est pas le cas, les conséquences sont minimales.
Pour créer de nouveaux logiciels, les développeurs utilisent le plus souvent des bibliothèques logicielles, mises à disposition par d’autres développeurs, qui offrent des fonctionnalités récurrentes facilement réutilisables (bases de données, primitives cryptographiques, calcul distribué, etc.). Comme tout logiciel, ces bibliothèques évoluent régulièrement pour intégrer de nouvelles fonctionnalités, corriger des bugs et failles de sécurité, améliorer les performances, etc. Ces évolutions sont empaquetées sous la forme de nouvelles versions. Les utilisateurs doivent se tenir à jour de ces nouvelles versions pour bénéficier de ces améliorations et se prémunir d’éventuelles attaques. Un exemple récent est la vulnérabilité Log4Shell qui rend possible l’exécution de code par des pirates sans que les utilisateurs n’en aient connaissance.
Lorsque ces nouvelles versions sont rétrocompatibles, le passage d’une version à l’autre se fait sans accroc pour les utilisateurs. Dans d’autres cas, les développeurs introduisent des changements dits « cassants ». Ces changements forcent les utilisateurs à réécrire leur code pour l’adapter à la nouvelle version. L'impact causé par l'introduction de changements cassants dans une bibliothèque peut se propager à travers tout un écosystème logiciel, avec des conséquences importantes. Ce fut par exemple le cas lorsqu’un développeur décida de retirer la bibliothèque « left-pad » de l’écosystème npm en mars 2016.
Afin d’aider leurs utilisateurs, les développeurs de bibliothèques utilisent des conventions de versionnage, et en particulier le versionnage sémantique. Dans ce dernier, un numéro de version prend la forme X.Y.Z, où X dénote la version majeure, Y la version mineure, et Z la version patch. La version majeure doit être incrémentée lorsque des changements incompatibles avec les versions précédentes sont introduits (2.3.1 à 3.0.0). Si la version majeure n’est pas incrémentée (2.3.1 à 2.3.2 ou 2.4.0), alors la nouvelle version doit être rétrocompatible. Cette convention de nommage très populaire permet aux utilisateurs de mieux choisir et anticiper l’impact des versions vers lesquelles ils migrent.
Malheureusement, les développeurs doivent s'en remettre à leur propre jugement pour décider du nouveau numéro de version de leur bibliothèque, et ils peuvent parfois se tromper. Il est difficile de savoir si une nouvelle version est rétrocompatible, en particulier lorsque de nombreux contributeurs y participent. Lorsque le nouveau numéro de version ne correspond pas, sémantiquement, aux changements apportés, les clients s’attendant à une mise à jour bénigne peuvent avoir à lourdement retravailler leur code pour l’adapter à la nouvelle version.
En analysant, à l’aide de nouveaux outils d’analyse statique, des centaines de milliers de bibliothèques et de clients écrits en Java et publiés ces quatorze dernières années, les travaux des chercheurs du LaBRI, publiés dans le journal Empirical Software Engineering, montrent que, contrairement à une croyance populaire dans le monde scientifique et l'industrie, les bibliothèques Java évoluent en fait de manière plutôt disciplinée : la grande majorité des contributeurs n'introduisent des changements cassants que dans les versions où c’est autorisé, et respectent donc le versionnage sémantique. Et, même lorsque des changements cassants sont introduits, ils n'ont le plus souvent que peu d'impact sur les clients. Les développeurs ont en effet tendance à cantonner les changements cassants aux parties peu utilisées de leur bibliothèque, et à minimiser leur impact. Une bonne nouvelle pour les développeurs qui peuvent donc le plus souvent se tenir à jour des bibliothèques qu’ils utilisent sans crainte !
Publication
Lina Ochoa, Thomas Degueule, Jean-Rémy Falleri, Jurgen Vinju. Breaking bad? Semantic versioning and impact of breaking changes in Maven Central: An external and differentiated replication study. Empirical Software Engineering, Springer Verlag, 2022, 27 (3)