Hello
Je pense que le mieux aurait été de faire une branche supportant spip 3.0 et que le trunk soit avec les bornes comme tu viens de faire, car maintenant ceux qui sont encore en spip 3.0 ne peuvent avoir que la version 2.5.11 comme version max alors que d'autres sont sans possible avec une version du plug en 3.x.x
C'est pour ça que quand il y a changement de borne de compatibilité, je pense que le mieux est toujours de faire une branche, même s'il n'y a pas de changement de "x" concernant la version (même si c'est toujours mieux).
Après à voir, cela se discute
de deux choses l'une
1. Soit les gens sont sous spip 3.0.0 et ont déjà formidable installé, et dans ce cas ils sont juste coincé dans les futures évolutions
2. Soit les gens sont sous SPIP 3.0.0 et veulent installer formidable, et dans ce cas ils sont poussés à passer à spip 3.1.0 ce qui
a) n'est pas compliqué
b) est conseillé en terme de sécurité
Si créer des branches lors d'une rupture de version pour une version de spip encore maintenue a du sens, ce n'est pas la même chose pour des versions non maintenu
au pire on pose un tags, mais pas une branche en tant que tel (qui suppose la possibilité d'évolution future sur cette branche)
Hello,
je crois au contraire que Franck a tout à fait raison :
quand tu changes l’intervalle de compatibilité comme ça, en supprimant la compat sur une version majeure il faut brancher et incrémenter la version de ton plugin d’une version majeure également.
Si on a une faille de sécu qu’on veut corriger sur les versions 3.x de formidable, on ne peut faire que du fix partiel qui sera pas déployable sur les anciennes versions.
Et a contrario, si tu veux installer un SPIP 3.0 avec une version compatible de formidable, tu es mort, il faut faire de l’archéologie pour retrouver la derniere version compatible
Et stop avec l’argument "SPIP 3.0 est plus supporté, la mise à jour c’est facile…"
C’est trop facile, totalement coupé de la réalité, et c’est présumer de ce que l’utilisateur veut/doit faire, on a pas le droit de flinguer comme ça des supports de version :
si je récupère un site en SPIP 3.0 avec une base en SPIP 3.0 et du code proprio en SPIP 3.0 et que je dois déjà le faire remarcher à l’identique avant de le faire évoluer je suis dans une grosse mouise…
faudra m'expliquer dans ce cas là pourquoi on fait plus de support de sécurité pour les branches 3.0 de spip, mais par contre les plugins eux devraient avoir un support sécurité sur cette branche.
A la rigueur un tag je comprendrais la logique, pour pouvoir reconstituer un état, mais une branche pour maintenir une compat ?
Bref, j'ai créé la branche, up le x sur le trunk et branché la génération du zip.
Sans vouloir insister et plus par pédagogie car ce ne sera surement pas un cas isolé on est en plein dans un usage où il faut créer une branche.
Changer la compatibilité de SPIP doit toujours passer par une branche afin de protéger l’existant.
Après ça ne veut pas dire qu’il faut apporter les modifications sur toutes le branches par la suite.
Je dirais même bien au contraire pour justement inciter le changement chez les users mais sans le forcer.
Il semblerait que depuis que Lars a réabonné toutes les listes qui étaient en gmane.org en gmane.io, tout ce qui est posté sur dev est aussi en copie sur zone.
Pire : Maïeul se retrouve posté 2 fois sur Zone à chaque réponse depuis quelque jours.
D'ailleurs, avec thunderbird :
J'étais dans devel.
J'ai fait répondre au groupe.
Et j'ai devel + Zone
(j'ai donc enlevé manuellement Zone)
Quand on poste sur devel SEUL, ça poste toujours sur les deux à la fois depuis une correction de Lars.
Lars qui a répondu à ma question sur les mauvais Message-Id, et qui a dit que c'était parce que "spip-dev" était alors inscrit avec DEUX adresses à la fois (apparemment depuis la fusion), c'est ça qui péter les fils.
Du coup c'est plus le même bug là, mais il y a toujours un truc à résoudre pour ne pas poster sur l'autre.
Et si up de x il y a, est-ce qu’on ne supprimerait pas la dépendance à Mini calendrier en ajoutant un test du plugin dans les squelettes (ou en le supprimant pour chacun puisse l’ajouté au besoin) ? A moins qu’il ne soit nécessaire au fonctionnement d’Agenda en dehors de ça ?
Ca devrait remarcher pour spip 3.0. Désolé (mais franchement je persiste à penser que si une version de spip n'est pas supporté, les plugins non plus devraient pas la supporter).
Pour le rapport avec le mini calendrier, je ne sais pas. J'ai jamais compris le lien de dépendance.
De toute facon il y avait un projet de refonte totale du plugin agenda. Mais bon c'est au point mort.
De mémoire le mini calendrier est aussi utilisé dans la saisie des répétitions des évènements multiples, non ?
Je n’ai plus tout en tête.
Mais pour l’histoire on m’a fortement suggéré de faire un plugin mini-calendrier séparé genre il y a plus de 10 ans, avec l’argument réutilisation, mutualisation etc.
Mais je ne crois pas qu’il soit utilisé pour autre chose, donc si simplification il devrait avoir, c’est plutot une fusion dans le plugin agenda.
Mais en l’état, non je ne pense pas qu’on puisse supprimer la dépendance
Mais du coup moi ça me fait poser une question peut-être naïve : si la modif des compats à SPIP est juste pour la forme et ne s'accompagne d'aucun ou à peu près aucun gros changement particulier : pourquoi le faire ?
Car du coup on se retrouve effectivement à avoir créé une nouvelle version *majeure* du plugin pour… rien. Alors que le chiffre X ça DOIT représenter quelque chose, et pour tous les utilisateurs, ça représente effectivement quelque chose ! Faut penser à leur réaction "Ah ce plugin est passé de 3 à 4, ya du changement !" Alors que non, rien, que dalle.
Si vraiment on veut ajouter une fonctionnalité qui nécessite impérativement une fonction qui n'est présente qu'à partir de telle version de SPIP, évidemment on peut/doit changer la compat, et du coup tout doit bouger. Mais si c'est juste pour faire du nettoyage, sans ajout pour les gens, ça peut peut-être attendre d'avoir besoin de faire des vrais ajouts qui justifient le up de X du plugin, et qui du coup est compréhensible pour les utilisateurs.
