il n’y a rien qui empêche de mettre à jour les sites de la galaxie
Non, rien c’est vrai, sauf peut-être le manque de temps, je crois que tu sais ce que c’est 
Tu coupes un peu l’idée 
qui était de parler de l’ordre (donc pour ce point sans travail vraiment en plus), càd que les sites officiels sont bien mis à jour à la dernière version à un moment, mais du coup s’assurer que dans la todolist ça soit fait avant de publier l’annonce finale.
C’est de l’amélioration continue par rapport à un premier bilan et aux retours des utilisateurices qu’il y a pu y avoir. C’est :
- faire plaisir aux devs qui veulent avancer en gardant ce rythme, c’est-à-dire renforcer le principe de freezer le contenu à un moment défini (ce que je plussoie totalement), ce qui force à de pas repousser réellement la release car choses en plus à tester, etc
- mais faire attention à pas décontenancer les utilisateurices en ne lançant pas la toute dernière étape (paquet et annonce sur sites) tant que ya pas une première salve de plugins validés
Par contre moyen chaud pour « les plus utilisés ». Le faire à l’arrache (et si c’est pas fait à l’arrahc qui va s’occuper des tests ?) risque d’entraîner des expériences pas très sympas pour les admins des sites qui les utiliseront, et surtout du support à assurer pour les personnes qui maintiennent ces plugins. Amha c’est à elle de le faire, quand elles pensent que le plugin a suffisamment été testé.
Oui oui… ce qu’on décide d’être à valider avant, j’ai bien dit c’est « à débattre »
Pas majeures non (ça c’est un saut de version X), c’est bien des versions mineures (saut de Y).
Version mineure c’est plus Z pour moi. Je disais majeure dans le sens grosse version quand même : ya des ajouts fonctionnels (Y) et parfois un peu de cassure/dépréciation. Et en premier lieu des plugins qui se désactivent car pas compat (ce qui n’arrive jamais avec Z, c’est la différence la plus évidente).
Du côté utilisateurices, enfin proprios de sites, une version de SPIP qui n’a aucun plugin disponibles, n’a rigoureusement aucun intérêt et ne permet pas du tout de lancer une mise à jour
Amha ça n’est pas le même problème ou la même question, cf mise à jour VS création/lancement d’un site. On sait très bien qu’on a une communauté qui a tendance a garder ses sites dans la versions pour laquelle il a été lancé, avec au min des mise à jour de patch (saut de Z).
Pas le même problème que quoi ?
Il me semble bien que c’est lié, pourquoi ne font-ils pas les mises à jour Y aussi ? Peut-être faut se poser ces questions aussi… C’est pas propre à notre communauté, c’est pareil pour un site en Drupal etc. On se gargarise (avec raison !) que contrairement aux autres nos mises à jour sont plus facile, qu’on essaye de casser le moins possible. Mais malgré ça, comme tu le dis ça n’empêche pas la majorité de garder le site avec la version X.Y de départ, en ne mettant à jour que les Z. Soit ya une raison sur laquelle on peut agir un peu, soit c’est commun à tout partout en fait.
L’autre partie des gens, c’est les personnes qui lancent de nouveaux sites, et c’est certainement de ce côté qu’on devrait plus communiquer (même si on le fait déjà pas mal) sur la possibilité de déverrouiller la compat max avec le define qui va bien. Ainsi on aurait plus de retours à propos des plugins, et surtout des retours plus sereins que quelqu’un qui panique parce que sont site en prod est pété suite à un passage de 3.2 à 4.1 en mode yolo ou par erreur à cause d’une bourde avec spip_loader ^^
Alors moi il m’était plutôt venu une idée un peu inverse : c’est surtout sur les mises à jour (mais oui ça peut l’être pour nouvelle install aussi), et notamment avec spip_loader qu’on pourrait imaginer des améliorations UX :
- dans l’interface de spip_loader, après choix de la version à installer, quand on détecte que c’est un changement Y ou X, afficher un gros message d’avertissement directement dans l’interface : « attention pour un changement important comme ça, veuillez toujours vérifier la disponibilité de l’ensemble des plugins, etc »
- dans spip_loader toujours, le mieux du mieux serait de permettre par une case à cocher (avant le début de l’install, justement au moment de l’avertissement par ex, ou sinon à la fin je sais pas) de pouvoir dire : « activer la compatibilité des plugins avec la version précédente de SPIP afin de pouvoir les utiliser même si pas encore compat ». Mais comme mes_options.php est pas forcément en écriture je vois pas comment ça pourrait. À minima en affichant un bloc de code à copier coller avec son explication (qui pourrait aussi contenir un « Si vous utilisez des plugins de la version précédente et que ça marche, nous vous invitons à les signaler sur… »).
De cette façon c’est directement à la source, au bon moment de la mise à jour, qu’on explique le problème en avance et ce qu’il faut faire. C’est toujours le meilleur endroit, par rapport à des articles de doc/annonce qui ne sont pas lus par tous, ou lus mais sans retenir tout par cœur non plus (et donc une fois devant l’écran en train de mettre à jour, on ne pense plus à tout : l’interface devrait être auto-suffisante au max).
fort peu se fait bénévolement pour le loisir
Je n’arrive toujours pas à partager ce constat, et s’il est avéré j’en suis bien attristé.
Tu te voiles la face mon pauvre José…
M’enfin je vois pas ce qu’il y a de si compliqué à voir, faire du logiciel pour le loisir, comme partout ailleurs, pas juste chez SPIP, c’est l’intérêt d’une minuscule minorité. Personne ne dit que ça n’existe pas, mais c’est une minuscule minorité. Pour la plupart c’est soit durant le temps de travail, ou soit même hors travail, c’est pas un loisir, c’est une utilisation « utilitaire » parce que tel logiciel (SPIP ou Ubuntu ou Framatruc) sert, est utile, aux assocs auxquelles on participe. Ça ne veut pas dire pour autant que c’est un loisir, un plaisir. Donc quand ya des mises à jour à faire, bah non, on fait pas ça sur notre temps le plus libre :
- quand c’est pour le travail, on fait ça sur le temps de travail donc, et pas gratuitement à priori : parce que des proprios de sites nous payent pour passer du temps à tester que ça marche et à le faire en prod (et si ces derniers veulent pas, bah la mise à jour attendra)
- quand c’est pour nos assocs, on fait ça quand on est vraiment obligé, ya déjà mille autres choses à faire concernant les vrais activités de l’assoc et ses besoins, donc quand le site marche, on n’y touche pas généralement
Mais en dehors de ça, bah on jardine, on fait du basket avec le gosse, on cuisine, on est en famille, on va voir un concert, faire un vide-greniers, etc.
Je ne souhaite pas donner de « leçon » aux pros (on est bien dans ce domaine là ?), mais ça n’est pas « juste pour rien » que ces sites doivent être mis à jour, ça leur assure une pérennité et certainement moins de mauvaises surprises (et donc des gain de coût) par rapport à un site n’évolue que par « gros paquet » tous les 5 ou 10 ans.
C’est là où il y a une incompréhension : c’est JAMAIS les pros qui choisissent de mettre à jour, sauf cas extrême où c’est obligé de chez obligé. Mettre à jour ça reste toujours in fine le choix des proprios des sites, car ça signifie toujours de passer du temps à tester que tout marche dans la version supérieure (core et plugins), corriger quand il faut, puis le faire en prod. Du temps donc de l’argent à payer aux prestataires qui vont le faire. Et donc une décision de le faire ou pas. Le « juste pour rien » il est jamais dit pas « les pros » mais bien par les proprios de site qui n’en voient pas l’intérêt. Et tant que le site marche tel quel et que la version est encore maintenue, bah généralement on le fait pas, on y reste.
Alors on peut argumenter, conseiller. Mais ça reste toujours leur décision.
Et si tu mets à jour gratuitement des sites de clients, par loisir, sur ton temps libre… bah t’es bien Gentil lol. 
Payer, payer, payer, tout ne se fait pour ça hein ^^ Et puis pour la 3.2, ça sera bientôt réglé, à moins qu’il y ait un nouvel élan de volonté collective dans le core (ou la communauté) pour maintenir cette version en vie
Cf plus haut, si, ça se paye, que ce soit les sites de clients qui payent un prestataire pour maintenir le site, ou asso qui va pas « dépenser du temps » en tests et mise à jour, tant que pas vraiment obligé, car ce temps est plus important à être passé sur les vraies activités de l’asso.
Mais oui 3.2 bientôt finie, mais justement ça va avec ce que je dis : j’attends donc ça avec impatience car ça permettra enfin de « forcer » les proprios à mettre à jour en pouvant leur annoncer que c’est plus maintenu du tout.
À ce sujet, je pense qu’il important qu’on lance une discussion pour qu’on fasse un état des lieux des motivations, disponibilités et surtout des envies des personnes du core. Sans ça, les quelques personnes qui tiennent SPIP (à bout de bras?) risquent de s"épuiser, d’attendre des gens, etc… alors que d’autres n’ont juste pas le temps ou l’envie et peut-être même culpabilisent de ne pas pouvoir donner assez :\
un Grand Débat National ?
un sondage ? une visio ?
–
RastaPopoulos
