Ou alors, corriger SVP en 4.3 pour que tout en autorisant les plugins 4.2, il charge les plugins pour 4.3 si disponibles…
Non !
Mais non plus…
Je précise que les plugins peuvent déclarer une compatibilité max avec une étoile, et dire ainsi qu’ils sont compatibles SPIP 4.* ce qui, si on arrive (ce qu’on tente) à respecter une compatibilité correcte (ie: à peu près semver), ne devrait pas poser de souci particulier. Ce qui correspond à ^4 ou ^4.0 dans le monde des dépendances Composer… et dire donc [4.1;4.*] devrait pouvoir dire à partir de 4.1 tout en restant dans la branche 4.
1 « J'aime »
Oui, sauf que l’immense majorité ont actuellement une borne 4.2.*
Et qu’une 4.3 sans réelle rupture de compat va pourtant, de fait, quand même en introduire une (incompatibilité) chez plein de gens.
Je sais, c’est pas simple… 
1 « J'aime »
Je pense que c’est justement le bon moment de modifier les bornes de compatibilité des plugins de 4.2.* en 4.*
2 « J'aime »
Yep, je le conçois.
Tu as une proposition de ce qui pourrait être fait ?
Ou on repousse tout simplement ?
Le 19/12/2023 à 10:29, Matthieu Marcillaud via Discuter de SPIP a écrit :
Yep, je le conçois.
Tu as une proposition de ce qui pourrait être fait ?
Ou on repousse tout simplement ?
Est-ce qu’on part du principe qu’à partir de maintenant, toutes les versions X.* ne cassent réellement rien de grave, rien d’important ? Il faut répondre « fermement » à cette question, car il me semble de mémoire qu’il y a eu quelques modifs quand même cassantes en 4.0 et 4.1, ou entre 4.1 et 4.2 je sais plus trop (d’API ou suite à des changements de compat PHP qui obligeaient à certaines modifs obligatoires pour pas que ça pète).
SI jamais la réponse est positive à partir de la 4.2 (et pour l’infini et au-delà), alors on pourrait communiquer officiellement et clairement là-dessus, et dire que majoritairement, la plupart des plugins peuvent désormais configurer une compat supérieure de 4.* dès maintenant (et plus tard dans la branche suivante pour 5.* dès le départ quand ça sortira si on continue de bien suivre le même principe), chose qu’on n’a jamais jamais faite depuis des années, on a toujours dit/montré l’exemple de mettre X.Y.* dans la borne supérieure.
Communication à faire un peu/assez en amont de la sortie de 4.3, pour que tout le monde ait le temps de changer la majorité des plugins en 4.*.
Et ensuite ça roule ?
–
RastaPopoulos
2 « J'aime »
Hé les gars vous pourriez bosser un peu pour releaser une version, mais svp changez pas le numéro qu’on ait pas à vérifier que nos plugins sont compatibles et qu’on puisse mettre tout à jour les yeux fermés hein, parce que nous on voudrait pas avoir trop de travail…
Ho Ho Ho ! Joyeux Noël
Autrement posé : serait ce t il pas raisonnable, justifié et plus fluide de considérer que les plugins compat 4.1 et 4.2 sont compat 4.* et corriger au moment où ils sont détectés, si jamais il y en a, les éventuels problèmes de compat à l’intérieur d’une même 4.* , plutôt que de faire « comme si » il y avait systématiquement des problèmes de compatibilité et forcer plugin par plugin à dire qu’il n’y en a pas ?
1 « J'aime »
Le 19/12/2023 à 11:12, cerdic via Discuter de SPIP a écrit :
Hé les gars vous pourriez bosser un peu pour releaser une version, mais svp changez pas le numéro qu’on ait pas à vérifier que nos plugins sont compatibles et qu’on puisse mettre tout à jour les yeux fermés hein, parce que nous on voudrait pas avoir trop de travail…Ho Ho Ho ! Joyeux Noël
Commentaire ironique qui évince l’expérience réelle des trois dernières années : il y a eu des mois et des mois de décalages entre les sorties des versions SPIP, et les compatibilités des plugins. Ce qui a occasionné des complications et des retards de mises à jour pour de nombreux sites tenus par des non-devs (je ne parle donc clairement pas des sites maintenus par des prestataires mais ça vaut parfaitement aussi quand ce sont des petites structures asso etc qui n’ont pas l’argent pour payer des màj plus longues que de raison s’il faut tester plein de compats).
La comparaison de marcimat avec composer où il est quand même courant de voir des compats X.* (^X chez eux) est intéressante. D’où la question parfaitement légitime et pertinente de savoir si on peut affirmer que désormais on suit mieux les semvers qu’avant, et que désormais il n’y aura plus (ou très très rarement) de cassures importantes à l’intérieur d’une même branche X (mais attention ça vaut pour la compat PHP qui parfois oblige à des modifs cassantes). Ce qui permettrait effectivement de mettre les plugins en X.* supérieur (chose qu’on n’a jamais fait pour l’instant), et les faire tenir plus longtemps, sans tests et maintenances trop rapprochés.
–
RastaPopoulos
2 « J'aime »
oui tout a fait. Finissons en avec ces bornes à 4.y pour préferer 4.*.
Ca nous forcera ainsi à renforcer la logique semver qu’on a globalement adopté ces derniers temps, à mieux séparer ce qui relève de la tambouille interne de ce qui relève des interfaces, bref à être plus propre.
1 « J'aime »
Et certainement d’autres petites choses que je n’ai pas en tête…
je pense au travail de @cerdic sur les nouvelle chaine de langue en balise dans les squelettes.
sur ce point les quelques cas que j’ai eu a traité concernait :
- des constantes publiques qui sont devenus des choses dans des classes (pour tout ce qui est parsing) ; mon avis c’est que c’est lié à la fois à une meclarté en amont de qui releve de l’interface ou pas et à un changelog public pas assez précis
- des changements dans les plugins-dist, notamment l’archiviste, mais là encore une logique semver pour les plugins dist + une dependance à la version de plugin-dist plutot qu’à SPIP lui même devrait résoudre ce problème.
Alors, en fait il faut tout de même faire attention, c’est qu’on a codé pour PHP 8.1+ dans SPIP 5.0-dev, et certains reports ça risque d’être aussi un peu de boulot quand même dans une 4.3 toujours compatible PHP 7.4
Je n’ai rien compris ? tu parles de quoi ?
Par ailleurs il faudrait migrer toutes ces constantes de SPIP en configuration. Cf #5187 - Service de configuration spip - spip - SPIP on GIT mais bon, c’est comme tout ^^.
Une nouvelle règle « par principe » de déclarer les plugins compat 4.x pour faciliter le travail des dev et éviter que les utilisateurs doivent attendre pour faire les mises à jour, c’est tout aussi mauvais (et même plus selon moi) : ça veut dire que les utilisateurs ils vont mettre à jour et leur site va casser car un ou des plugins ne seront pas compatibles.
Donc en gros on compte sur les utilisateurs pour tester les plugins et faire le sale boulot parce qu’on a eu la flemme de le faire (ou qu’on était trop occupé à troller sur discuter.spip.net au lieu de se remonter les manches).
Maintenant chaque mainteneur peut bien faire comme il préfère, notamment au regard de la complexité du plugin et des apis internes qu’il utilise dans SPIP.
C’est clairement pas le même problème pour un plugin comme NoSpam ou un plugin comme Saisies, donc je vois pas comment une règle « par principe » va marcher bien, et ça me semblerait une très mauvaise idée que quelqu’un passe sur tous les plugins pour mettre à l’aveugle un 4.*.* partout
ce genre de chose
Je suis d’accord qu’il y a certains plugins plus ou moins complexes. Et saisies est sans doute un des plugins les plus complexe parce qu’il mêle notamment plusieurs niveaux (css/html/PHP).
Cela étant c’est aussi l’un des rares plugins à disposer d’un jeu de tests unitaires conséquents, avce la possibilité de savoir facilement de quelle fonction internes de SPIP on a besoin.
Pour ma part je maintiens que si nous faisons vraiment du semver et si nous avons vraiment des changelog et UPGRADE.md tenu à jour, ce qui est globalement le cas, les cas de rupture potentiel pourraient se detecter plus facilement… et donc nous permettre de focaliser nos tests sur ceux qui valent le coup.
Est-ce qu’on veut vraiment s’imposer cette contrainte de PHP 7.4 compatible ?
La question de reporter ou pas est indépendante des autres questions. Les éventuels reports vraiment nécessaires de la 5 vers la 4 sont probablement très cernés et le reste c’est du luxe, n’est il pas ?
Une nouvelle règle « par principe »
Où donc as-tu vu parler de « par principe » 
alors que depuis X messages la question principale (et ce n’est pas une question rhétorique mais une vraie question) est bien : est-ce qu’on est désormais assez semver depuis quelques versions, pour pouvoir affirmer que rien de trop grave sera cassé à chaque nouvelle version ? La question n’est pas du tout la même en 2019 ou avant, et là en 2023.
SI jamais la réponse est positive à partir de la 4.2 (et pour l’infini et au-delà), alors…
Impliquait forcément que SI la réponse est non (pour X raisons, je ne fais absolument aucun jugement là dessus !), alors bien évidemment qu’il ne faut pas mettre de compatibilité X.*, et que faut continuer comme on le fait pour l’instant. Et basta.
Mais c’était évident, si on lit bien les questions en entier et qu’on ne préjuge pas que les autres auraient déjà une certitude sur la réponse à apporter… 
(ce qui n’est pas le cas)
Ce questionnement ne vaut vraiment que si on considère que récemment (et à l’avenir), le noyau est assez semver pour ne pas occasionner de cassure majeure entre 4.2 et 4.3 (puis 4.4 si ça existe, ou ensuite entre 5.0 et 5.1, 5.2 etc).
Ça existe bien ailleurs, par ex là Drupal Commerce (gros truc complexe pourtant), qui indique nécessiter tout Drupal 9.*
(Parler de troll sur des discussions parfaitement légitimes et rationnelles, c’est un peu la loi de Godwin du codeur non ?)
Quand on dit
Ce qui permettrait effectivement de mettre les plugins en
X.*supérieur (chose qu’on n’a jamais fait pour l’instant),
c’est qu’on parle d’une règle de principe. Sinon on aurait parlé de "mettre des plugins en X.* "
Donc je répondais à ce que tu as littéralement écris, pardonne moi de ne pas avoir répondu à ce que tu voulais dire même si tu as écris autre chose…