These are chat archives for shaarli/Shaarli

21st
Jul 2015
Alda Marteau-Hardi
@Aldarone
Jul 21 2015 07:36
Humpf, je suis plutôt de l'avis d'ircmaxell là dessus ( http://blog.ircmaxell.com/2014/12/on-php-version-requirements.html ) : Si on permet aux utilisateur d'aller chez un hébergeur troué, l'hébergeur en question n'a aucun intérêt à mettre à jour sa version de PHP. Par contre si les gens peuvent pas utiliser tel logiciel sur leur hébergeur, ils auront une bonne raison d'en partir. Et un hébergeur qui voit ses clients se barrer va peut-être se poser des questions.
Bref, je pense que c'est pas aux développeurs de se tenir aux versions obsolètes mais aux hébergeur de se tenir à jour.
VirtualTam
@virtualtam
Jul 21 2015 23:20

Avoir des serveurs à jour, c'est l'idéal, on est d'accord... Sauf que l'utilisateur n'a pas toujours le choix, ni les moyens (financiers, techniques), voire la volonté, de s'assurer de la stabilité et de la sécurisation de son environnement, puis de le maintenir.

L'article que tu cites (ainsi que la suite, dispo sur le même site) me semble un peu biaisé (et rageux, aussi, mais en sécurité et en admin sys, on a le droit) : il s'intéresse principalement aux projets (moteurs et cadriciels de publication) d'échelle industrielle : Wordpress, Drupal, Apache, Nginx...
Évidemment, si l'un d'eux s'annonce incompatible avec "la version X de la bibliothèque Y", les hébergeurs vont se remuer. Enfin, devraient. Dans l'idée. Je tombe régulièrement sur le c** quand je croise des Debian old-old-stable, voire des Ubuntu Server 10.04 sur des parcs de production (on ne parlera pas de Wintrucmuche, ni de Java / Java EE, ça donne de l'urticaire).

En pratique, il faut garder à l'esprit que Shaarli est un outil de sauvegarde de liens, mono-utilisateur, et auto-hébergé ; au vu de l'état actuel du code, qui nécessite un bon coup de jeune, ça ne me paraît pas raisonnable de forcer ce genre de restrictions, qui vont principalement :

  • gêner des utilisateurs, qui risquent soit d'arrêter de mettre à jour leur Shaarli, soit de se tourner vers un autre projet
  • générer inutilement des rapports de bogues, donc du temps passé à diagnostiquer des non-problèmes

C'est sûrement un peu démago, mais je préfère assurer la rétrocompatibilité du code, tout en préconisant l'utilisation d'un serveur à jour / stable. Et puis rien ne te garantit qu'un serveur "à jour" n'a pas été configuré avec les gros orteils : la doc, les fofos et les blogs PHP sont truffés d'avertissements au sujet de modules obsolètes (certains non maintenus depuis plusieurs années comme mcrypt), qui sont pourtant massivement utilisés.

À titre de comparaison, ça n'est pas parce que tu roules en 205 qu'un garagiste va refuser de changer les pneus, ni t'encourager à faire le tour du monde avec. Et ça sera toujours "moins pire" que des pneus lisses.

Histoire de conclure, j'ai tout de même l'impression que la communauté et l'écosystème PHP se sont améliorés ces derniers temps, et cherchent à rattraper leur retard sur des langages plus modernes / modulaires (qui a dit Python/Django/Pylons/Flask ?) : PEAR / Composer pour la gestion de bibliothèques et dépendances, PSR pour définir des conventions de codage et d'architecture communes, PHPUnit & co pour tester le code.
Beaucoup moins "bidouille-bricolage" qu'il y a 4-5 ans.