| prefix | spip_compatibility | sites | spip | last_commit |
|---|---|---|---|---|
| accesrestreintobjets | [4.0.0;4.1.*] | 4 | 4.0;3.2 | 2023-05-31 |
| ascore | [3.2.0;4.1.*] | 0 | N/A | < 2023-02-23 |
| chapitres | [3.2.0;4.1.*] | 0 | N/A | 2024-05-17 |
| connexionparip | [4.0.0;4.1.*] | 0 | N/A | < 2023-02-23 |
| dayfill | [4.0.0;4.1.*] | 0 | N/A | < 2023-02-23 |
| dayfill_factures | [4.0.0;4.1.*] | 0 | N/A | < 2023-02-23 |
| docker | [3.0.2;4.1.*] | 1 | 2.1 | < 2023-02-23 |
| doc_tech | [3.0.9;4.1.*] | 0 | N/A | 2023-04-14 |
| emplois | [4.0.0;4.1.*] | 3 | 3.2 | < 2023-02-23 |
| formifusion | [3.0.0;4.1.*] | 4 | 3.2;3.0 | 2023-05-12 |
| formidable_rio | [4.0.0;4.1.*] | 0 | N/A | < 2023-02-23 |
| historique_spip32_h3 | ]3.2.999;4.1.*] | 1 | 4.3 | < 2023-02-23 |
| htmlpurifier | [4.1.0;4.1.*] | 5 | 3.2;3.1 | < 2023-02-23 |
| naturaliste | [4.0.0;4.1.*] | 0 | N/A | 2023-08-27 |
| periodes | [3.0.0;4.1.*] | 2 | 3.2 | < 2023-02-23 |
| playht | [3.2.0;4.1.*] | 0 | N/A | < 2023-02-23 |
| prix_objets_periodes | [3.0.0;4.1.*] | 2 | 3.2 | < 2023-02-23 |
| projets_organisations | [4.0.0;4.1.*] | 0 | N/A | < 2023-02-23 |
| reglements | [4.0.0;4.1.*] | 0 | N/A | < 2023-02-23 |
| reservation_bank | [3.0.20;4.1.*] | 3 | 3.2 | < 2023-02-23 |
| reservations_credits | [3.0.20;4.1.*] | 0 | N/A | < 2023-02-23 |
| spipmine | [4.0.5;4.1.*] | 0 | N/A | < 2023-02-23 |
| spip_400 | [3.0.0;4.1.*] | 12 | 4.0;3.2;3.1;3.0 | < 2023-02-23 |
| svpbase | [4.1.0-dev;4.1.*] | 0 | N/A | < 2023-02-23 |
| html5up_phantom_multidomaines | [4.0.0;4.1.*] | 0 | N/A | 2023-06-15 |
| SpipClear | [4.0.0;4.1.*] | 7 | 3.2;2.1;2.0 | < 2023-02-23 |
J’ai corrigé formidable_rio, pour le reste connais pas 
T’aurais peut-être pu faire un y+1 au lieu d’un z+1 mais ok, cool.
T’aurais peut-être pu faire un
y+1au lieu d’unz+1
j’ai hésité, mais pour moi le fait qu’on ait un limitation sur une meme branche x de SPIP c’est plutot un bug/erreur de conception. Donc j’avais pensé z+1. Mais bon ca se discute, et si pour l’avenir on décide autrement ca me va aussi.
ça peut pas être un bug, la notation ET la garantie du respect de semver n’arrive qu’après, c’est donc une amélioration
Et donc, en fait, non, ça ne se discute pas tellement. Un chagement dans les dépencences, c’est une amélioratiion, pas un bug.
Enfin … te biles pas, hein. C’est pas choquant non plus.
Mais oui, j’ai bien l’intention qu’on arrive à un consensus par groupe git (où se croisent des projets git et des mainteneureuses, qui choisiront et feront appliquer leurs règles …)
Alors Naturaliste c’est un plugin que j’ai en développement.
Et svpbase c’est l’extraction du référentiel des plugins de SVP que j’ai commencé en 4.1 avec un fol espoir de scinder SVP en deux en 4.2. On y est pas mais le plugin a toujours son sens.
Donc je m’occupe de faire évoluer ces deux là.
Je note qu’il y a pas mal de plugins de Rainer et j’ai l’impression qu’il ne fait plus de mises à jour.
Les 4 plugins de @Rainer_Muller de ce tableau
- prix_objets_periodes
- reservation_bank
- reservations_credits
- periodes
je vais les mettre en compat 4.*
Ça ma parait un peu présomptueux, il y a probablement pas mal de choses à reprendre dedans pour une compat ascendante.
Il y a aussi le plugin reservation, dans ceux que je connais, que tu as déjà passé 4.*
J’avais dû faire une adaptation en urgence pour SPIP 4.1 dans celui ci :
Et de ce que j’en avais vu, c’est vraiment pas sûr que ça passe en 4.2
D’ailleurs le site sur lequel je l’avais mis en place (ils sont autonomes) l’a désactivé en passant en 4.2
Et puis, compatibilité SPIP 3.0 → 4.* pour tous ces plugins de @Rainer_Muller, ça me parait casse gueule aussi…
En fait, semver arrive après, si je ne dis pas de bêtise, en cours de 4.2 non ?
Parce que en 4.2, il y a eu des choses qui cassaient des utilisations de 4.1.
Mais mon système cognitif me joue des tours depuis quelques mois, je n’ai pas de réf là sous la main.
Oui tout à fait, surtout sur des constantes pour des regepx et autres, qui sont basculés en collecteurs.
Il me semblait bien.
Du coup, basculer des plugins 4.1. * en 4.* c’est un peu chaud.
Je serais pour revert ça.
Faudrait aller au delà des apparences et des impressions à mon avis. Et ne pas se mettre la pression inutilement si les plugins sont peu ou pas ou plus utilisés …
Il y a quelques mois, c’était 1 constante qui posait problème, entre 4.1 et 4.2, pour certains plugins qui l’exploitaient. En tout cas, j’en étais resté, de ce que j’ai pu lire en tout cas, à quelques cas de plugins, à la marge.
Maintenant c’est « des constantes », c’est très flou… S’il y a plein de cas d’incompatibilité, comment expliquer qu’il y a 2,5 fois plus de SPIP4.2 vérifiés que de 4.1 ?
Ces tableaux, je les mets en ligne pour que ça avance : pour que les plugins trouvent des mainteneureuses, éventuellement les re-dispatcher dans des nouveaux groupes git, ou pour les archiver en masse.
J’ai moi même rencontré plusieurs incompatibilités en faisant des mises à jour SPIP 4.2 → 4.2
Je ne les ai pas notées à chaque fois.
Alors c’est à la marge oui, pour des utilisations parfois limite, mais ça existe.
J’ai vu que tu en avais déjà passé plusieurs en compat 4.*
- periodes
- reservations_credits
- reservations_bank
- prix_objets_periodes
Ceux de rainer spécifiquement ? Je serai pour les revert.
Pour les compat ->4.1.*, il vaut mieux laisser les mainteneurs décider au cas par cas, j’y vois des gens qu’on connaît sur les derniers commits : @rastapopoulos @cerdic @maieul @erational @pierretux
[EDIT]
Pour les incompatibilités 4.1 → 4.2, le typage des arguments, par exemple, m’avait provoqué quelques erreurs fatales dans les squelettes
Autre exemple : dans un formulaire CVT, si _charger() ou _verifier() sont déclarées sans rien renvoyer, le formulaire n’est pas traité.
Exemple :
function formulaires_machin_verifier_dist(){}
et en 4.2, le formulaire s’arrête là, il ne fait rien.
J’ai mis à jour historique_spip32_h3 il fonctionne.
connexionparip ne fonctionne pas, mais peut être à cause de ipset dont il dépent (qui est compat → 4.0 seulement)
Je viens de faire un framacalc :