Hello,
Ca serait cool d’y penser sans que Francky soit obliger de toujours passer derrière.
Merci pour lui 
Le 05/08/2019 à 20:21, Eric Lupinacci a écrit :
Hello,
Ca serait cool d'y penser sans que Francky soit obliger de toujours passer derrière.
Merci pour lui
J'avais effectivement mis 3.0 dans la borne inférieure du paquet que j'ai créé pour ce plugin.
Les paquet.xml ça marche pour SPIP 2 ?
On maintient toujours SPIP 2 ?
--
nicod_
Hello,
Le mar. 6 août 2019 à 04:45, nicod_ <nicod@lerebooteux.fr> a écrit :
Le 05/08/2019 à 20:21, Eric Lupinacci a écrit :
Hello,
Ca serait cool d’y penser sans que Francky soit obliger de toujours
passer derrière.
Merci pour luiJ’avais effectivement mis 3.0 dans la borne inférieure du paquet que
j’ai créé pour ce plugin.Les paquet.xml ça marche pour SPIP 2 ?
On maintient toujours SPIP 2 ?
En fait c’est pas le sens de la modification de Franck.
Souvent il corrige le numéro de version qui diverge entre les deux XML.
Le sens de la modification est : les deux fichiers décrivent le même plugin et le même paquet, ils ne devraient pas être différents donc.
C’est pourquoi j’ai toujours milité pour éviter ce doublon au profit d’une branche.
Mais bon, bientôt on en sera débarrassé.
++
Eric
Le 06/08/2019 à 08:51, Eric Lupinacci a écrit :
Le sens de la modification est : les deux fichiers décrivent le même plugin et le même paquet, ils ne devraient pas être différents donc.
Pourquoi ? (vraie question)
C'est pourquoi j'ai toujours milité pour éviter ce doublon au profit d'une branche.
Sauf que tout le code est le même pour 2.0 et 3.0
Mais bon, bientôt on en sera débarrassé.
Oui, on pourrait supprimer le plugin.xml, mais en même temps c'est con parce que ça marche bien sur SPIP 2
Mais bon, SPIP 2...
--
nicod_
Hello,
Le sens de la modification est : les deux fichiers décrivent le même
plugin et le même paquet, ils ne devraient pas être différents donc.Pourquoi ? (vraie question)
Ben en fait, la logique est la suivante :
- en SPIP 2 : seul plugin.xml est connu donc utilisé
- en SPIP 3 : paquet.xml est scruté en premier, puis plugin.xml sinon (même heuristique d’ailleurs pour smart-paquets quand il construit le zip et le fichier des archives).
Coté configuration, le XML qu’il soit paquet ou plugin décrit UN paquet donné (cad une version ,un zip).
Il n’y a donc aucune raison, que pour une branche donnée d’un plugin, le paquet et le plugin qui décrit la même chose aient des différences.
Il ne faut pas considérer avec quel SPIP il est utilisé mais ce qu’il décrit, en l’occurrence un même paquet (au sens zip).
C’est pourquoi j’ai toujours milité pour éviter ce doublon au profit
d’une branche.Sauf que tout le code est le même pour 2.0 et 3.0
Oui, comme quand on démarre une branche.
La question est doit-on continuer à faire évoluer les deux branches ?
Moi j’ai toujours beaucoup de réticence à le faire car souvent pour un saut majeur comme SPIP 2 SPIP3 on a des facilités qu’on ne peut pas utiliser et cela complexifie le code du trunk ce qui n’est pas top je trouve.
Enfin, je sais que sur ce sujet je ne suis pas en accord avec la tradition SPIP mais franchement quand tu vois un code qui n’évolue pas parce qu’il faut garder la compat avec des trucs antédiluviens, je dis bof bof !
Mais bon, bientôt on en sera débarrassé.
Oui, on pourrait supprimer le plugin.xml, mais en même temps c’est con
parce que ça marche bien sur SPIP 2
Mais bon, SPIP 2…
Et bien là on en revient au sujet précédent car il faudra bien interdire la compatibilité avec SPIP 2 avant d’enlever le plugin.xml.