Hello Eric, Denis, Fil, ...
@Eric : Tout d'abord, je tiens à te dire explicitement que je suis très
respectueux (et reconnaissant) du travail de toute la communauté SPIP, et
aussi de sa philosophie du libre: j'avais donc potassé la page
http://plugins.spip.net/redaction-du-paquet- xml.html AVANT de toucher au
moindre paquet.xml. Cette page n'interdit pas ni ne déconseille de numéroter
un plugin sur le modèle
"version majeure de SPIP - version majeure du plugin - révision du plugin". Le
changement de version était de toute façon rendu indispensable par
l'incompatibilité factice crée par une borne sup trop basse, signalée par
Franck sur SPIP-Contrib, et ça m'a semblé une bonne idée d'en profiter pour
faire ce saut de version afin que celà soit plus clair pour les utilisateurs.
A part ça je suis effectivement un dév "poilu" (je suis barbu), mais Fil a
publié ce jour (15h01:16) sur spip-zone un post où il dit "J'y ai un peu
réfléchi en me rasant et je trouve qu'il n'y a pas de moyen simple de sortir
du sac de noeuds."
Je partage donc l'opinion de Fil (sauf pour le rasage matinal ...) :
- "s'obliger à tester et renuméroter presque un millier de plugins à chaque
révision mineure du core me paraît dangereusement démotivant.".
Je pense que les évolutions du core doivent donc s'assurer de ne pas casser de
compatibilités quand ce n'est pas absolument inévitable en raison de l'ajout
de fonctionnalités nouvelles.
A terme, l'idéal serait de prévoir des tests unitaires normalisés au niveau
des plugins (et des "noisettes" incluses dedans, bien entendu), afin de
permettre aux développeurs du core de tester rapidement la compatibilité des
évolutions avec TOUT l'existant.
Fil propose néanmoins plusieurs pistes qui me semblent meilleures que
d'obliger tout développeur de plugin à mettre à jour des bricoles (voire un
simple numéro de version) parce qu'une compatibilité ascendante aurait été
cassée trop vite lors d'une évolution du core de SPIP.
Il me semble ESSENTIEL que l'excellente compatibilité ascendante qui a
contribué au succès de SPIP depuis de nombreuses années reste une priorité
lors des évolutions du core, et que les règles de versionnement ne créent pas
d'incompatibilités factices, comme celà s'est produit pour Palette avec SPIP
3.1.0-dev (svn).
L'idée de Fil d'un outil de gestion d'un tableau des compatibilités me semble
excellente, et je voudrais suggérer en plus que tout signalement
d'incompatibilité dans un tel outil soit lié à l'outil de suivi de bugs et de
features requests. Des mails automatiques aux développeurs de plugins ET DU
CORE seraient un plus : si un dev ne corrige pas une incompatibilité signalée
au bout d'un temps raisonnable, alors on pourrait considérer qu'il s'agit d'un
développement abandonné ?
@Eric : les "corrections de bornes" de près de 800 plugins n'étaient pas une
bonne solution, AMHA, pour trois raisons :
- celle que Fil a signalé : c'est à refaire à chaque évolution même mineure du
core;
- si c'est nécessaire, c'est peut-être bien parce que la compatibilité
ascendante du core a été traitée plus légèrement que par le passé;
- et surtout, c'est un changement "philosophique", un renversement de
perspective (qui me déplait), entre la volonté de moderniser régulièrement le
core et le souhait légitime des développeurs d'avoir un core ultra-stable
facilitant les développements sur cette plateforme.
Je pense que certains points d'entrée du core devraient être "ultra-stables"
et à défaut prévoir des fonctionnalités de compatibilité quand la
modernisation du core impose des changements (fonction find_in_path(),
pipelines, modalités de surcharge des fonctions du core, ...).
Encore une fois, développer un mécanisme solide et global de tests unitaires
normalisé pour les développements hors du core serait sans doute une meilleure
solution, plus fiable. Il y a déjà eu des tentatives dans cette direction;
peut-être sont-elles à moderniser, elles aussi ?
Bien cordialement,
dF
Le lundi 28 mai 2012 10:40:54, vous avez écrit :
Hello Daniel,
Après la question, je vais expliquer mes motivations sur le sujet.
Pour le numéro de version, ce qui m'a choqué c'est qu'aucun commit
préalable ne justifiait le changement. Donc dans le cycle de vie du plugin
on voit à un moment un saut incompréhensible sur le x (de x.y.z) qui
devrait signifier une incompatibilité.
La sortie de Plugins SPIP a justement été l'occasion de "rationaliser" un
peu ces concepts pour une meilleure visibilité pour tous.
L'explication est ici :
Rédaction du paquet.xml - Plugins SPIP
Le 28 mai 2012 02:20, Daniel FAIVRE <webmaster@geomaticien.com> a écrit :
> Scénario plus courant, qui se produira avant :
> - le plugin "truc" a comme borne sup 3.0.99
> - SPIP 3.1 sort
> - le plugin "truc" n'est plus reconnu comme compatible, alors qu'il l'est
> ...
> - avec mon SPIP 3.1.0, je ne retrouve plus le plugin "truc", pourtant
> compatible, dans la liste ...
Oui mais celui-là n'est pas problématique et "protège" le webmestre.
Alors oui, le dev poilu ça le fait chier car il "perd" son plugin qu'il
savait (le dev est magicien par essence) fonctionner.
L'interface de SVP est pas top lors que cela se produit, il faudra y
remédier plutôt que réouvrir toutes les bornes. Fil a déjà fait une liste.
En outre, Denis vient de rajouter un define pour outrepasser ce
comportement et cela me parait plus intéressant comme démarche car c'est
une démarche de dev.
Enfin, on a passé des semaines à corriger les bornes de près de 800 plugins
de la zone afin qu'ils annoncent leur vraie compatibilité affichée sur
Plugins SPIP : j'ai pas trop envie de perdre cet acquis.
Et tu ne t'imagines pas combien de plugins plus compatibles depuis 1.9.2
avaient une borne sup ouverte comme tu dis qui annoncait compatible jusqu'à
la fin des temps.
Et mettre un borne sup à une valeur x apporte plus d'informations (au moins
j'ai testé ça marche) que de la fermer un jour hypothétique.
Voilà
++
Eric