La plupart du temps, leur nom n’indique pas du tout l’état du contenu : est-ce une version stable, alpha, en re-release ?
Et la gestion via archivelist.txt des sabots ne facilite pas la chose.
Je propose donc qu’un travail de normalisation soit fait, en même temps que l’organisation SVN.
A minima, je suggère une organisation comme pour http://files.spip.org/spip/
en 3 répertoires :
derniere-stable/ → les plugins dans leur version « la plus stable possible » (ex. Forms&Tables pour spip-1.9)
dev/ → Les plugins dans leur version de développement (ex. même plugin pour spip-2.0)
stable/ → Les anciennes versions stables ou archives des branches de maintenance
Je suggère également qu’on ne trouve pas d’homonymes dans les différentes branches.
Pour faire simple, il me semble logique de reprendre la structure en branche SVN.
(voir http://trac.rezo.net/trac/spip-zone/wiki/MiseEnBranche)
En particulier, si on a un trunk SVN, alors l’archive de celui-ci « devrait » en principe se trouver dans le répertoire stable/
Sinon pour clarifier les choses pour celui qui télécharge le plugin, je suggère de TOUJOURS lui affecter le numéro de la dernière version de SPIP avec lequel il est compatible, ou alors un nom générique de type mon_plugin-1.9+
Par exemple :
=> pour saveauto, on aurait un derniere-stable/saveauto-1.9.2.zip, dev/saveauto-2.0.zip, stable/saveauto-1.9.1.zip
L’avantage d’une telle organisation est que :
les plugins pourraient être rangé automatiquement dans le bon répertoire si on se calque sur le statut défini dans plugin.xml (mais l’usage de ce statut c’est un autre débat)
leur nom pourrait être calculé automatiquement à l’aide des infos de plugin.xml :
donne la version de SPIP
donne la partie générique du nom
des scripts de recherche de mise à jour pourraient détecter qu’une nouvelle version existe,
on pourrait à l’avance savoir (un script pourrait le faire) si la modification de la version de SPIP va faire planter nos plugins existant, ou s’il existe des versions (stables ou en dev) qui seront compatibles avec la version qu’on a l’intention d’installer
- Le numéro de la version de SPIP dans le nom, je trouve ça confus car on confond avec la version du plugin lui-même (qui du coup n'est pas visible d'ailleurs). En plus si une même archive fonctionne sur plusieurs versions de SPIP à la fois, ça rajoute à la confusion. On est plus sûr de rien, et ça n'aide en rien pas à la lisibilité directe.
- La plupart des contribs actuelles sont distribuées sous forme *technique* de plugins (avec le plugin.xml, etc). Mais il y a dedans à la fois des vrais plugins (ou plutôt "extensions") qui *ajoutent* une fonctionnalité ou un outil particulier. Et il y a des squelettes.
En ce qui me concerne, j'aime donc assez ajouter le terme "plugin" ou le terme "squelette" dans le nom du ZIP des contribs que je fais. Ça permet de savoir tout de suite à quoi on a affaire.
plugin_agenda.zip
squelette_tma.zip
plugin_contact.zip
squelette_zesty.zip, etc
Le numéro de la version de SPIP dans le nom, je trouve ça confus car on confond avec la version du plugin lui-même (qui du coup n’est pas visible d’ailleurs). En plus si une même archive fonctionne sur plusieurs versions de SPIP à la fois, ça rajoute à la confusion. On est plus sûr de rien, et ça n’aide en rien pas à la lisibilité directe.
Oui tu as raison : un numéro de plugin doit apparaître dans le nom de l’archive. Le plus simple à mon avis est de prendre le numéro de version, au moins, ou d’un numéro personnalisable (ex. 0.9beta).
Par contre, le fait que le plugin soit supporté par telle version de SPIP me semble être une info incontournable.
On se retrouverait alors avec des dénominations semblables aux packages Linux, par exemple.
mon_plugin-1.9b-spip-1.9.1.zip
mon_plugin-1.9b-spip-1.9.2.zip
mon_plugin-2.0.1-spip-2.0.zip
ou par défaut
mon_plugin-r13578-spip-1.9.1.zip
mon_plugin-r14600-spip-1.9.2.zip
mon_plugin-r14600-spip-2.0.zip
Et à la limite, si plusieurs archives sont générés pour un plugin qui supporte différentes versions de SPIP, ça ne me semble absolument pas génant.
La plupart des contribs actuelles sont distribuées sous forme technique de plugins (avec le plugin.xml, etc). Mais il y a dedans à la fois des vrais plugins (ou plutôt « extensions ») qui ajoutent une fonctionnalité ou un outil particulier. Et il y a des squelettes.
En ce qui me concerne, j’aime donc assez ajouter le terme « plugin » ou le terme « squelette » dans le nom du ZIP des contribs que je fais. Ça permet de savoir tout de suite à quoi on a affaire.
plugin_agenda.zip
squelette_tma.zip
plugin_contact.zip
squelette_zesty.zip, etc
oui pourquoi pas.
On pourrait ainsi scinder le plugin agenda en 2 parties : une partie fonctionnelle plugin_agenda et un habillage par défaut squelette_agenda (ou
La plupart du temps, leur nom n’indique pas du tout l’état du contenu : est-ce une version stable, alpha, en re-release ?
Et la gestion via archivelist.txt des sabots ne facilite pas la chose.
Je propose donc qu’un travail de normalisation soit fait, en même temps que l’organisation SVN.
A minima, je suggère une organisation comme pour http://files.spip.org/spip/
en 3 répertoires :
derniere-stable/ → les plugins dans leur version « la plus stable possible » (ex. Forms&Tables pour spip-1.9)
dev/ → Les plugins dans leur version de développement (ex. même plugin pour spip-2.0)
stable/ → Les anciennes versions stables ou archives des branches de maintenance
Bof.
A mon avis
un plugin en dev n’a pas de raison d’être distribué en .zip, les developpeurs etant priés d’utiliser SVN de toute façon
files.spip.orgn’est pas un espace de distribution mais un espace de stockage. C’est à la documentation sur contrib d’expliciter d’assurer la distribution et donc le classement et l’organisation, et de mettre à disposition l’archive concernée pour chaque version de SPIP.
Je suggère également qu’on ne trouve pas d’homonymes dans les différentes branches.
Pour faire simple, il me semble logique de reprendre la structure en branche SVN.
(voir http://trac.rezo.net/trac/spip-zone/wiki/MiseEnBranche)
En particulier, si on a un trunk SVN, alors l’archive de celui-ci « devrait » en principe se trouver dans le répertoire stable/
Sinon pour clarifier les choses pour celui qui télécharge le plugin, je suggère de TOUJOURS lui affecter le numéro de la dernière version de SPIP avec lequel il est compatible, ou alors un nom générique de type mon_plugin-1.9+
Par exemple :
=> pour saveauto, on aurait un derniere-stable/saveauto-1.9.2.zip, dev/saveauto-2.0.zip, stable/saveauto-1.9.1.zip
L’avantage d’une telle organisation est que :
les plugins pourraient être rangé automatiquement dans le bon répertoire si on se calque sur le statut défini dans plugin.xml (mais l’usage de ce statut c’est un autre débat)
leur nom pourrait être calculé automatiquement à l’aide des infos de plugin.xml :
donne la version de SPIP
sauf que l’info est foireuse pour plein de plugin depuis la passe d’etiquetage automatique et sans dicernement qui a eu lieu…
un plugin en dev n’a pas de raison d’être distribué en .zip, les developpeurs etant priés d’utiliser SVN de toute façon
SPIP est bien distribué en version ‹ dev › sous forme de zip. Il ne faut pas non plus oublier que lors du passage de spip1.9.2 à spip2.0, on a vu pas mal de plugin stable repasser en dev (vis-à-vis de la dernière version de SPIP). A l’avenir, l’installeur automatique devrait pouvoir installer des plugins, même en version dev., selon moi.
files.spip.orgn’est pas un espace de distribution mais un espace de stockage. C’est à la documentation sur contrib d’expliciter d’assurer la distribution et donc le classement et l’organisation, et de mettre à disposition l’archive concernée pour chaque version de SPIP.
Selon moi, files.spip.org est un peu comme un répertoire de fichiers rpm pour Linux
L’installation automatique peut piocher dedans
Pas mal de doc sur spip-contrib pointent vers ces fichiers
Des scripts de test de mise à jour peuvent s’appuyer dessus
Ce n’est certes pas un lieu avec de la doc explicative, mais cet espace devrait donner accès à l’ensemble des plugins à ceux qui n’ont pas svn
Je suggère également qu’on ne trouve pas d’homonymes dans les différentes branches.
Pour faire simple, il me semble logique de reprendre la structure en branche SVN.
(voir http://trac.rezo.net/trac/spip-zone/wiki/MiseEnBranche)
En particulier, si on a un trunk SVN, alors l’archive de celui-ci « devrait » en principe se trouver dans le répertoire stable/
Sinon pour clarifier les choses pour celui qui télécharge le plugin, je suggère de TOUJOURS lui affecter le numéro de la dernière version de SPIP avec lequel il est compatible, ou alors un nom générique de type mon_plugin-1.9+
Par exemple :
=> pour saveauto, on aurait un derniere-stable/saveauto-1.9.2.zip, dev/saveauto-2.0.zip, stable/saveauto-1.9.1.zip
L’avantage d’une telle organisation est que :
les plugins pourraient être rangé automatiquement dans le bon répertoire si on se calque sur le statut défini dans plugin.xml (mais l’usage de ce statut c’est un autre débat)
leur nom pourrait être calculé automatiquement à l’aide des infos de plugin.xml :
donne la version de SPIP
sauf que l’info est foireuse pour plein de plugin depuis la passe d’etiquetage automatique et sans dicernement qui a eu lieu…
C’est peut-être une raison supplémentaire pour mettre un peu d’ordre dedans, non ?