Derrière ce jeu de mots digne d’une personne aisée qui habiterait le pauvrissime seizième arrondissement de Paris, il se cache une question sur la fiabilité d’une référence récurrente dans le monde du logiciel : La numérotation.
Point de repère indispensable en cas de dépannage, cela donne aussi lieu à des concours de « c’est moi qui a la plus grosse », spécialement dans le domaine des navigateurs internet. Entre septembre 2008 et fin avril 2016, Google Chrome est passé de la version 1 à la version 49 (ou 50 ?), Mozilla Firefox étant passé de la version 3.0.2 à la 45 (ou 46).
Il faut dire que la mise en place du processus de publication à intervalles réguliers (6 à 8 semaines) ont lancé une folie qui tourne au grand n’importe quoi.
Pour info, faisant compiler régulièrement le code source des pré-alpha de Mozilla Firefox, j’ai eu la bonne surprise d’avoir le 25 avril 2016 une version 49.0a1. Ce qui veut dire que la version alpha (ou développeur) est la 48, la version béta la 47. Quel concours d’appendice génital 🙂
En dehors de ce concours, savoir quelle version est utilisée est souvent bien pratique… Tant que des numérotations différentes et parfois cryptique ne sont pas employées. Un article posté sur le blog de Denis Szalkowski m’a mis la puce à l’oreille.
Dans cet article où il parle d’Ubuntu 16.04 LTS en version serveur, il la compare avec la Fedora 23 au niveau de la fraicheur relative des paquets de LAMP (qui permettent de monter un serveur web pour héberger des outils comme WordPress, Dotclear, Joomla et bien d’autres choses encore).
On peut lire :
[…]
En terme de fraîcheur des paquets LAMP, Ubuntu 16.04 fait globalement mieux que Fedora 23 sur le plan applicatif, notamment en proposant le PHP 7.0 :kernel 4.4.0 (plus frais pour Fedora, en 4.4.7)
[…]
C’est ici qu’une information partiellement inexacte fait son apparition. Le schéma de numérotation du noyau de la Ubuntu est particulièrement… imbuvable.
Sur la page d’information du paquet linux-image pour la Ubuntu 16.04 LTS, au 26 avril 2016, on peut lire ceci :
linux-image-4.4.0-21-generic (4.4.0-21.37)
On pourrait donc en déduire que c’est un noyau linux 4.4.0… Alors que dixit kernel.org, en date du 26 avril 2016, la version conseillée du noyau 4.4 est la 4.4.8, sortie le 20 avril.
Quoi ! Ubuntu proposerait une version non rustinée du noyau ? Pas vraiment.
Si on regarde le suivi des changements, on s’aperçoit que le noyau proposé est au minimum basé sur la révision 4.4.6. Source ? Juste un bug trouvable sur l’outil de suivi de launchpad, le 1558330 dont le titre est parlant : « Xenial update to v4.4.6 stable release »
Modification apportée le 21 mars. Une personne qui n’irait pas sur la page du paquet pour jeter un oeil à l’historique des changement apportés dirait : Pourquoi Canonical ne mets pas à jour son noyau ? Il est mis à jour, seulement la numérotation est imbuvable.
Dommage de ne pas suivre la numération proposée en amont. Mais ne tomberait-on pas dans le principe énoncé dans un proverbe des Shadoks : « Pourquoi faire simple quand on peut faire compliqué ? »
La numérotation, c’est pratique… Quand elle est la même pour tout le monde 🙂
Enfin, je dis cela, mais je dis rien au final. Sans rancunes, j’espère ?
« La numérotation, c’est pratique… Quand elle la même pour tout le monde » tu voulais sans doute dire:
« La numérotation, c’est pratique… Quand elle est la même pour tout le monde »
Enfin, je dis cela, mais je n’ai rien compris au final.
Corrigé, merci !
Ma pensée est allée plus vite que mes doigts sur la fin 🙂
Pour ma part, j’utilise la date au format YYYY-MM-DD comme numéro de version.
C’est simple, incrémental, ça permet de savoir quand le machin a été publié … et accessoirement ça permet de super bien se positionner à qui a la plus grosse 😉
Ha ouais ? Tu t’embêtes vraiment à compiler Nightly ? Chez moi ça prend facilement entre 25 et 40 minutes 🙁 Je n’ai vraiment pas la patience pour compiler quoi que ce soit… Je crois qu’une installation de Gentoo pourrait mettre fin à ma vie.
Perso, à la place j’ai un mini script qui (avec makepkg) va me chercher le .tar.bz2, me fait un package et me l’installe avec pacman. Ça me prends 4 minutes, et c’est automatique. Il y a un package AUR qui fait ça aussi… Firefox-always-nightly.
Je préfère par habitude qui remonte à l’an 2000 faire compiler directement le code source sur ma machine. Ce qui m’a permis de faire remonter des bugs de compilation. Et en cas de problèmes de lancement, j’ai toujours une archive.