+1
Je n’osai pas poster de remarque sur ce « choix » ne participant que de très loin à la vie de SPIP… mais je vois que d’autres écrivent ce que je pense (et je serai étonné d’être le·la seul·e) donc je me le permets respectueusement même si j’ai bien compris que cela partait (surement) d’une très bonne idée mais peut-être un peu trop orientée développeur/informaticien·ne et je me retrouve très bien dans le cas n°1 évoqué par Rasta.
Merci de m’avoir lu.
Cordialement,
Pascual23
De : RastaPopoulos via Discuter de SPIP noreply@discuter.spip.net
Envoyé : mardi 12 juillet 2022 14:50
À : pascal@editions-jpm.fr
Objet : [SPIP][Dev] Aujourd’hui, quelle nouvelle version installer pour du long terme ?
 |
RastaPopoulos Juillet 12 |
|---|
Le 12/07/2022 à 13:51, b_b via Discuter de SPIP a écrit :
On n’avait pas abordé le sujet dans Proposition Roadmap SPIP (court terme), et Composer. https://discuter.spip.net/t/proposition-roadmap-spip-court-terme-et-composer/157863 mais on pourrait y réfléchir. La principale contrainte étant les disponibilités de l"équipe à maintenir toutes ces LTS (même si la date de fin de support annoncée pour la 3.2 est fin 2022).
Il me semble aussi que c’est un sujet, et il faudrait bien entendu faire la balance de ce que ça coûte (ou pas tant, ça se trouve, justement à évaluer) en surplus de temps de maintenir au moins une version plus longue que les autres en permanence.
Par comparaison, il me semble qu’à peu près tous les autres CMS ou frameworks importants ont ce système (à un instant T il y a toujours une version maintenue plus longtemps que les autres). https://symfony.com/releases
Ensuite de ce que je connais par expérience, avec les gens pour qui je fais/installe des sites, il me semble que les cycles courts sont handicapants autant pour les très petits (petites assos etc), que pour les gros (institutionnels, collectivités, etc). En gros il n’y a que les « moyens » que ça va intéresser (c’est beaucoup dire…) ou au moins qui seront capables de suivre, pour deux raisons différentes :
· les petits, n’auront jamais le budget ou le temps perso interne (ça revient au même), pour mettre à jour aussi souvent ; ils vont donc laisser des versions en retard, et ne plus être super au niveau sécu (en premier lieu, le plus important) ou au niveau fonctionnel (ils resteront avec des plugins anciens pour leur plus vieille version)
· les gros, ce n’est pas juste une question de budget, mais ils n’aiment généralement pas mettre à jour sur des versions fréquentes qui sont obligatoirement, de fait, alors moins testées, moins maintenues, avec moins de plugins stables disponibles, etc : les collectivités et grosses institutions cherchent du stable, qui ne va pas bouger pendant un moment, pour le core mais aussi donc pour les plugins qui ont alors le temps d’être vraiment stables (pas « demi ok », comme pas mal de trucs mis pour 4.X trop tôt et qui ont ensuite pas mal de corrections avant d’être réellement ok)
Les moyens eux, auront peut-être le budget ou les ressources internes pour mettre à jour plus souvent, et peut-être que ça leur plait plus d’être « au top à jour ». Mais donc on laisse à la traine de nombreux utilisateurs existants (dont tous les petits), qui peuvent avoir de bonnes raisons de chercher d’autres solutions plus stables (ou bien ils s’en foutent et arrêtent et publient sur FB, au moins c’est maintenu en permanence :p).
Bref faut en discuter, et voir ce qui est acceptable (sans avoir plusieurs LTS, je pense qu’une seule à la fois doit suffire), et ce que ça implique. Perso j’ai du mal à me faire une idée de ce que ça implique.
–
RastaPopoulos
Voir le sujet ou répondre à ce courriel pour répondre.
Pour vous désabonner de ces courriels, cliquez ici.