Le format tar ne compresse pas par défaut. Et "compacteur", ça fait un peu poubelle...
Pourquoi pas Archiviste ? Ça désigne bien le gestionnaire, alors que "archive" désigne ce qui est archivé...
CM
Ok, pourquoi pas. J'espère que la distinction suffira 
Archiviste une fois !
Archiviste deux fois !
Des objections ?
MM.
Je propose "Casserole" !
Héhé 
Sinon, est-ce que ce ne serait pas une bonne idée de revoir un peu la
manière dont on nomme les plugins ?C'est un peu agaçant de devoir sans cesse trouver des synonymes pour
trouver un préfixe disponible... D'autant que tout les bons préfixes
semblent déjà utilisés.Est-ce qu'il ne serait pas possible d'avoir un système d'espace de nom ?
Oui, c'est pour cette raison que les namespaces ont été introduits dans PHP aussi (5.4). Ça offre un peu plus de libertés dans les nommages.
Je vois quelque façon de faire :
core:zipper : Plugin dans le core
zone:zipper : plugin de zipper de la zone
Il est toujours possible de préfixer le préfixe ^^ (même sans :).
Si on passait à une utilisation avec ':' ou '\' ça sous entendrait qu'on utilise réellement des espaces de noms (en PHP il s'entend), sinon le problème va se reposer avec le nom des fonctions / fichiers appelés ({prefixe}_fonctions.php) par exemple. Et ça impliquerait (les espaces de noms indiqués dans le paquet.xml) d'autres complications.
Ceci étant dit ça n'empêche pas que le mot Archive est employé en français et ici pour les choses plus ou moins différentes. Et que ça soit core_archive d'un coté et plugin_archives de l'autre ne changera pas beaucoup cette situation.
MM.
Moi j’opterais pour Archives de fichiers qui dit bien ce pour quoi le plugin est fait.
Un préfixe archfile par exemple.
Et un préfixe du type : Gérer vos archives de fichiers zip, tar et pouet
Au contraire, je trouve ça très bien
JL
gogogo
Coucou,
c'est un préfixe pas un nom. inutile de faire compliqué et surtout moi je
préfère sans _ pour le repérer plus facilement.
Eric il est où le "" dans Archiviste ? --
Suis la conversation
Hop,
Coucou,
^^ Gogogo
Surtout si tout le monde est content 
Coucou,
Du coup pourquoi ne pas packager 3.2-alpha maintenant, là, tout de suite ?
Là je ne vois plus trop de bonnes raisons et les “gaps” trop grand entre les versions, ce n’est pas toujours rigolo à gérer après pour les utilisateurices.
J’avais le sentiment que la discussion sur ce point avait aboutie en ce sens, me trompe-je ?
Des bises
Du coup pourquoi ne pas packager 3.2-alpha maintenant, là, tout de suite ?
Là je ne vois plus trop de bonnes raisons et les "gaps" trop grand entre
les versions, ce n'est pas toujours rigolo à gérer après pour les
utilisateurices.
+1
Ça enverrait un message positif, et ça permettrait aux gens de commencer à la tester, et surtout à tester les plugins.
Certains ne passeront peut être pas directement (mise à jour de jQuery/UI), il faudra peut être gérer une liste des plugins compatibles comme on l'avait fait pour la 3.1
J'avais le sentiment que la discussion sur ce point avait aboutie en ce
sens, me trompe-je ?
Oui, et puis sûrement une petite baisse d'énergie/motivation ?
Du coup pourquoi ne pas packager 3.2-alpha maintenant, là, tout de suite ?
Là je ne vois plus trop de bonnes raisons et les "gaps" trop grand entre
les versions, ce n'est pas toujours rigolo à gérer après pour les
utilisateurices.+1
Ça enverrait un message positif, et ça permettrait aux gens de commencer à la tester, et surtout à tester les plugins.
+1 aussi.
Et pourquoi pas une bêta direct? Parce qu'il me semble que le gap est sur les plugins qui utilisent les anciennes versions de jquery.
Tout le reste semble bien fonctionner et sans doute beaucoup de plugins aussi.
Il faudrait d'ailleurs enlever la compatibilité forcée avec les plugins 3.1 actuellement par défaut en 3.2
Jacques
(je voulais dire, pour les gens qui n'utilisent pas SVN)
Hop,
Du coup je fais ça tout à l'heure sauf si ça ne vous va pas ?
Ça me va pour ma part. Ça fait pas mal de choses à tester déjà.
Il faudra voir si on peut pas mettre à jour d'autres lib javascript suite à la sortie de jQuery 3.2 (qui vent d'être mise dans SPIP 3.2).
MM.
En plus des libs, il y a 2 plugins-dist qui "utilise" des plugins de la
zone:
https://zone.spip.org/trac/spip-zone/browser/core/plugins/textwheel/paquet
.xml
https://zone.spip.org/trac/spip-zone/browser/core/plugins/medias/paquet.xm
l
Textwheel utilise "yaml" et " memorization"
Donc, à voir s'il faut supprimé le fait que la 3.2 accepte les plugins de la
3.1 au moins le temps que "yaml" et "mémorization" ne sont pas dit,
compatible spip 3.2
Medias utilise "z" là, c'est de l'historique, car déjà du temps de spip 2.0
alors que cela ne faisait pas parti de la dist
https://zone.spip.org/trac/spip-zone/browser/tags/mediatheque_spip_2_0/plugi
n.xml#L90
Mais si je regarde l'historique des commits, il ne semble plus y avoir
beaucoup de mouvement le concernant
https://zone.spip.org/trac/spip-zone/log/squelettes/zpip-dist/branches/zpi
p_v1
Donc, d'après vous, il est encore utile/judicieux d'avoir ce "utilise",
perso, je serais pour le supprimer, car, s'il n'y a plus de support, alors
c'est une source de risques; mais en même temps, sachant qu'il fonctionne en
3.1, cela risque d'être un frein pour ceux qui voudraient se mettre en 3.2
s'il ne fonctionne pas par manque de se "utilise"
Franck
-----Message d'origine-----