On nous vend depuis des années l’idée que les distributions Linux en fixed release doivent tenir un cycle de publication « raisonnable ». Traduction : pas trop court pour éviter l’usine à gaz, pas trop long pour ne pas finir en fossiles. Et pourtant, certains projets persistent à croire qu’un cycle de 3, 4 ou même 5 ans est viable. Pas vraiment au final.
Le problème des cycles trop longs ? Il y en a trois.
- Logiciels obsolètes : attendre 3 ans pour une mise à jour majeure, c’est condamner l’utilisateur non professionnels à traîner des versions dépassées de sa suite bureautique ou de son environnement de bureau. Dans un monde où Firefox (cycle mensuel) ou LibreOffice (cycle semestriel avec mises à jour mineures mensuellement), c’est suicidaire.
- Sécurité : maintenir pendant des années des paquets vieillissants, c’est multiplier les patchs et les rétroportages. Autant dire que c’est une sacrée utilisation de ressources pouvant être théoriquement employées ailleurs.
- Attractivité : qui veut installer une distribution figée dans le passé ? Les utilisateurs non professionnels finissent par migrer vers des des fixed releases plus dynamiques, voire des rolling release pour les plus courageux.
Deux ans, c’est une limite plutôt pragmatique, pour plusieurs raisons.
- Rythme des projets en amont : la majorité des logiciels libres suivent un cycle rapide, d’un mois à six mois en moyenne. Deux ans, c’est déjà généreux.
- Charge de maintenance : les équipes de développement ont souvent pris pour habitude de ne conserver que deux versions en même temps. La version actuelle et celle qui l’a précédé. Un exemple ? LibreOffice, avec une version « ancienne » dite stabilisée et une récente qui est plus dynamique. Mais la version ancienne reste utilisable.
- Équilibre entre utilisateurs et développeurs : deux ans, c’est assez long pour garantir une certaine stabilité. Tout en restant gérable.
Il y a un seul cas où les deux ans ne sont pas applicables, c’est celui du monde de distributions à destination des entreprises. Comme ce sont des entités qui changent rarement le matériel informatique – du moins tant que celui-ci n’est pas rincé – un cycle long est préférable. Mais ce sont souvent des distributions adossées à de grosses structures comme RHEL qui est maintenue par IBM. Ce qui nécessite de rétroporter des patchs, d’utiliser des paquets universels quand la vieillesse commence à se dévoiler.
Pour conclure ? Si on se place dans le monde de l’utilisateur non professionnel, les deux ans sont la limite acceptable. Ni trop court, ni trop long, ce cycle est donc idéal. Reste le problème de rétroporter les correctifs de sécurité, mais la plupart des fixed release contournent leur fixité en ce qui concerne les navigateurs en utilisant par exemple la version ESR (long terme) de Mozilla Firefox.
C’est sûrement le seul contre-exemple (du moins, c’est celui qui me vient directement à l’esprit) dans la tradition de ne bouger qu’à la marge des fixed releases.
