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…
Le 19/12/2023 à 14:07, cerdic via Discuter de SPIP a écrit :
c’est qu’on parle d’une règle de principe. Sinon on aurait parlé de "mettre /des/ plugins en |X.*| "
Si tu parles de ça, on met bien des 4.1.* alors qu’il y a des 4.1.Z qui sortent non ? C’est une règle de principe tacite ? C’est bien qu’on considère depuis toujours que le risque est faible d’avoir une cassure entre 4.1.2, et 4.1.3, etc. La question est donc là-maintenant la même pour de 4.2 à 4.3, 4.4, etc, si jamais on considère qu’en suivant semver par la suite, il n’y aura pas de cassure majeure.
Ça n’a jamais été le cas avant car il y a toujours eu des cassures entre Y et Y+1 du core, mais maintenant est-ce que le choix de suivre plus fortement le versionning standard (ce qui est de plus en plus le cas, ça ne fait que se bonifier sans prétendre être parfait) ferait que dans la plupart des cas (ce qui n’empêche pas d’avoir 1 ou 2 exceptions mais ça inverse le rapport du passé) ça autoriserait à dire que seul le X majeur va vraiment casser, et que donc la plupart des plugins pourraient être compat 4.* (puis 5.* plus tard) ?
–
RastaPopoulos
Nouvelle proposition après discussions chore(roadmap): update dates (!25) · Merge requests · James / supported-versions · GitLab
On décale la sortie de la 5.0 d’un an et on allonge le support des versions 4.2 et 4.1 en conséquence.
À noter, on aura tout le loisir de sortir une 4.3 compatible PHP 8.3 dans 6 mois si l’envie est là.
Avec une sortie de SPIP 5.0 en 2025, sa version de compatibilité PHP ne serait-elle pas PHP 8.4 ?
Peut-être bien que oui 
1 « J'aime »
Oui pour php max en 8.4 assez logiquement… la question de PHP mini va se poser aussi d’ailleurs, car 8.1 ne sera plus supporté par PHP également !
Coucou,
Cela nécessitera « de l’abnégation et un peu de motivation » comme on dit, mais ça me semble une meilleure idée que de sortir une 4.2.z compatible PHP8.3 et ainsi de suite tant que SPIP4.2 sera maintenue.
2 « J'aime »