Des chercheurs ont étudié la façon dont les bibliothèques logicielles (libraries) évoluent à travers leurs développements. En effet, il est difficile, en tant que développeur, de savoir si on peut avoir confiance dans la nouvelle version d’une bibliothèque.
Théoriquement, les mainteneurs donnent un numéro de version qui permet de savoir si la modification est majeure, mineure ou est un correctif : 2.0.0. Si le premier nombre évolue, les changements sont non rétrocompatibles. Si le deuxième change, la version contient des ajouts de fonctionnalités rétrocompatibles. Et si c’est le troisième, elle n’apporte que des corrections d’anomalies rétrocompatibles. Mais est-on sûrs de pouvoir faire confiance aux développeurs de la bibliothèque ? C’est toujours un casse-tête et pourtant ne pas mettre à jour expose aussi à des risques de sécurité.
Des chercheurs du Laboratoire Bordelais de Recherche en Informatique et de l’Université de technologie d'Eindhoven ont analysé près de 120 000 bibliothèques et près de 300 000 clients Java publiés ces quatorze dernières années et ont constaté que 83 % utilisaient la bonne nomenclature pour leurs différentes versions. Leur article titré « Breaking bad? Semantic versioning and impact of breaking changes in Maven Central » a paru dans la revue Empirical Software Engineering volume (PDF).
Commentaires (20)
#1
“ont constaté que 83 % utilisaient la bonne nomenclature”
Un changement du premier numéro n’est pas forcément causé par une modification non rétro compatible, cela peut aussi marquer un changement majeur rétro compatible, comme une nouvelle apparence ou un ajout d’une grosse fonctionnalité qui nécessite un changement de numéro pour “marquer le coup”. Il y a aussi ceux qui changent de version tous les ans dans un but purement marketing ou qui ne suivent pas cette notation (exemple : Ubuntu).
C’est la nomenclature la plus courante, pas celle qui convient à tout le monde.
#1.1
Ca ne casse pas la bonne nomenclature.
La seule exigence est que si tu as un changement non rétrocompatible, alors tu dois changer le numéro de version majeure. Mais rien ne t’empêche de le modifier même s’il n’y a aucun changement non rétrocompatible.
#1.2
Après, il est ici formellement question de bibliothèques logicielles, donc Ubuntu n’est pas vraiment un bon exemple pour le coup
#2
De toute façon la meilleure nomenclature de version, c’est celle de LaTeX
#3
La meilleure numérotation c’est MD5(sources)
#4
Effectivement quand le semver est respecté ça a un côté rassurant pour intégrer une nouvelle version sans risquer de créer de la régression. Par contre si c’est pas respecté et qu’un patch contient un breaking change, ça commence à craindre… (vu plusieurs fois dans des projets de dev interne chez des clients où ils se contentaient de bêtement faire +1 avec trouze mille features embarquées dont des breaking changes…)
L’autre aspect important de respecter le semver, c’est aussi pour générer des releases notes cohérentes et classées par type d’ajout pour pouvoir la lire plus facilement.
#5
On est sauvé les librairies java sont bien rangés, c’est tellement restrictif que je ne suis meme pas sur que ça représente quelque chose
#6
C’est d’ailleurs car tout est si bien rangé que depuis au moins 15 ans, tout machin codé en Java est livré avec sa JVM et ses dépendances pour être certain d’avoir un truc fonctionnel! Bonjour le poids du “Hello World” niveau sumo.
Et si cela restait limité à Java… ou à l’applicatif windows. Quand on voit du snap arriver jusqu’a Linux ou les dépendances dans une distribution étaient bin gérées car tous les outils sont là, on n’est pas le cul sorti des ronces.
Il faudrait que mémoire et stockage se mettent à enfler sur la courbe de prix du GWh gaz ou électrique pour que le gâchis s’arrête.
#7
Quand on travaille sur des bibliothèques ou des API, en effet respecter Semantic Versioning est à mon sens un must. Par contre on peut avoir des breaking changes sur des versions qui se suivent, cf. la FAQ de la stratégie de versioning, mais quand ça arrive ça doit être :
De manière générale si le numéro de version a une sémantique, il ne suffit pas à la prise de décision quand on change de version de dépendance, il est juste le marqueur d’un niveau de risque. Disposer d’une bonne documentation et communication dans ce cas reste primordial.
#8
Ça manque un peu de « sémantique », non ?
#9
Oui.
83% du temps.
Donc non.
#10
Peut-être justement que Java ne s’adresse pas à ceux qui veulent faire un hello world?
Et sinon y’a un truc qui s’appelle graalvm, qui existe depuis un peu plus de 3 ans, et qui permet de faire en java à peu près tout le contraire de ce que tu dis :)
#11
On appelle ça un numéro de commit Git (aux détails près que c’est du SHA1 + légers détails).
#12
Le C permet de coder un OS complet (Java, même pas en rêve), faire un hello world léger… Et un applicatif compilé il y a 1 ou 2 décennies dont on aurait perdu les sources a toutes chances de tourner encore sans gros pb de dépendance cassée.
#12.1
On a eut JavaOs pour de l’embarqué chez Sun
#12.2
À ma connaissance, JavaOS est un OS qui sert à faire tourner exclusivement des applis en Java, mais le noyau lui-même n’est pas en Java.
#12.3
Euh, si si. Au départ il s’appuyait sur le microkernel Chorus (qu’ils ont racheté par la suite).
https://en.wikipedia.org/wiki/JavaOS
#12.4
JavaOS est construit sur le micro-noyau Chorus (pas que “au départ”, c’est juste qu’après ils ont racheté Chorus Système, donc c’était toujours le même, mais c’était désormais une techno maison).
Vu que le projet Chorus date de 1979 et que la première release Java est en 1995, ça serait balèze que Chorus ait été en Java.
En cherchant 2 minutes : https://www.cl.cam.ac.uk/teaching/2000/ConcSys/csig2/62.html (point 24-5).
#13
Rien de très bas niveau n’est écrit en langage objet. Pas même en C++ pourtant compilé natif. La raison est le manque de maîtrise des allocations que le moindre new va générer. Alors on en reste au C, qui a pour le moment éliminé tous les candidats à sa succession (en attendant Rust?).