Bonjour,
Aujourd’hui un nouveau site SPIP n’a aucune pérennité à long terme car la version maintenue n’a qu’une durée de vie de quelques jours/mois.
J’aimerais que la version 4.1 soit l’équivalent de la version 3.2, avec une annonce de support jusqu’en 2025.
Le problème est que pour longtemps il me sera impossible d’installer la version 4.2 car les plugins ne sont pas prêts.
Est-ce qu’une version 4.x est une version TLS ?
Bonne journée,
.Gilles Vincent
Tu es peut-être passé à côté des échanges à propos du nouveau cycle de release où on explique que le but est de suivre celles de PHP ?
Cette version est compatible de PHP 7.4 à 8.1 (tout comme la 4.2), je ne crois pas que ces versions de PHP sont supportées jusqu’en 2025 cf https://www.php.net/supported-versions.php
Tu peux commencer par installer une 4.1, ensuite le passage vers la 4.2 passera sans problème, l’essentiel étant que les personnes qui maintiennent les plugins testent et valident la compatibilité de ceux-ci. À ce sujet, il y a eu échange ici Ecosystème d'une version SPIP et on a maintenant une page de suivi https://plugins.spip.net/spip.php?page=statistiques&type_stats=noupd-tag&tag=usage-galaxie qui montre qu’une bonne partie des plugins fréquemment utilisés sont compatibles avec SPIP 4.1 (et donc bientôt avec la 4.2).
On n’avait pas abordé le sujet dans Proposition Roadmap SPIP (court terme), et Composer. 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).
PS : s’il doit y avoir une LTS sur la branche 4, je pense que ça devrait être la dernière version de la branche en question, donc potentiellement la 4.2.
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 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
Hello,
amha la 4.1 va avoir une vie plus longue que prévue initialement, car force est de constater qu’il nous a fallu a peu près 3 mois pour arriver à faire le tour des plugins courants et maintenus, les tester et mettre à jour leur compatibilité pour SPIP 4.1 (en parallèle de tout le reste évidemment, c’est à dire le dev normal, notre vie, la release des patchs de secu etc…). Du coup la vraie vie de la version 4.1 commence tout juste…
Je pense qu’une nouvelle release tous les 6 mois, si elle correspond aussi au support d’une nouvelle version PHP, va avoir un coût latéral de maintenance assez disuasif.
De fait, à ce jour on a pas vraiment eu le temps de travailler sur du contenu d’une version 4.2 et une nouvelle release aurait potentiellement peu de changements… (il me semble)
+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.