Salut,
je comprends pas pourquoi tu parles de mise à jour du plugin picto, il n'a pas bougé :
https://git.spip.net/spip-contrib-extensions/picto
spip-contrib-extensions/fontawesome5
-
Par erational, le 25 septembre 2020 à 11h59min :mise à jour du plugin picto à la version fontawesome 5
Salut,
je comprends pas pourquoi tu parles de mise à jour du plugin picto, il n'a pas bougé :
spip-contrib-extensions / picto · GitLab
Hello
désolé ma formulation n'est pas heureuse
j'ai repris le code de picto pour avoir un plugin autonome qui charge la librairie font-awesome à la version 5
(voir la discussion précédente par email)
Ok.
En fait y'aurait un truc possible, si tu nommes ton fichier principal font-awesome.min.css exactement comme dans picto :
https://git.spip.net/spip-contrib-extensions/picto/src/branch/master/picto_pipelines.php
comme ça, ce serait ta lib fontawesome5 qui serait utilisée par picto (surcharge) si les deux sont installés, si tu me suis ?
je ne veux pas toucher à picto car il embarque font-awesome 4.7 et c'est très bien
le jeu de glyphes n'est pas le meme que font-awesome 5.1 et le nom des classes a aussi évolué avec une rupture de compatibilité (la class fa devient fas ou fab selon le sous-jeu de glyphes)
comme pour les plugins boostrap, j'aimerai qu'on propose des plugins pour embarquer les versions majeures de ces libraires de facon simple d'où mon plugin indépendant
suis-je plus clair ?
Pour moi oui.
En revanche pour l'instant je ne comprends toujours pas l'intérêt d'avoir des plugins réellement différents (= autre préfixe) pour chaque version de ce qu'on embarque.
Le principe du versionning sémantique c'est justement pour permettre de dire que quand on change la version X (dans X.Y.Z) c'est un changement majeur qui casse la compatibilité antérieure. Donc quel intérêt de carrément changer de plugin pour ça, alors que les numéros de version servent précisément à ça ?
Concrètement pourquoi un plugin prefix="fontawesome5" et non pas un unique plugin "fontawesome" ayant des branches Git "branches/v4", "branches/v5", "branches/v6", etc ?
Je sais qu'un argument est que ça empêche les gens de mettre à jour "automatiquement" vers une version majeure différente qui casserait leur site. Mais on a alors ce problème pour TOUS les plugins du monde qu'on a et qui changeraient de version X. Pourtant on ne le fait pas pour chaque plugin du monde. Quand le plugin Patates passe de 2.3.4 à 3.0.1, on ne fait pas un prefix="patates2" et un prefix="patates3", même quand ça casse le fonctionnement (ce qui est souvent le cas si on décide de changer X).
Si on a un problème ergonomique avec SVP quand il gère et prévient les gens des mises à jour : c'est ça qu'il faudrait corriger absolument, pas faire un préfixe par version majeur de plugin, non ?
RastaPopoulos a écrit le 26/09/2020 à 12:05 :
Je sais qu'un argument est que ça empêche les gens de mettre à jour "automatiquement" vers une version majeure différente qui casserait leur site. Mais on a alors ce problème pour TOUS les plugins du monde qu'on a et qui changeraient de version X. Pourtant on ne le fait pas pour chaque plugin du monde. Quand le plugin Patates passe de 2.3.4 à 3.0.1, on ne fait pas un prefix="patates2" et un prefix="patates3", même quand ça casse le fonctionnement (ce qui est souvent le cas si on décide de changer X).
Si on a un problème ergonomique avec SVP quand il gère et prévient les gens des mises à jour : c'est ça qu'il faudrait corriger absolument, pas faire un préfixe par version majeur de plugin, non ?
Dans la mesure où SVP a un bouton "Cocher toutes les mises à jour", et un comportement identique quel que soit les risques de la mise à jour, je trouve que le choix de changer de préfixe est tout à fait cohérent.
Entre autre, parce que ça permet de faire avancer un plugin sur 2 branches, tout en permettant de faire les mises à jour sans se poser de questions.
(PS : c'est la même chose avec le plugin foundation)
Hello,
Tu réponds ça en citant très exactement la phrase qui explique bien que c'est justement ÇA qu'il faut corriger…
Et je ne vois pas le rapport que ce soit Bootstrap, Foundation, FontAwesome, ou n'importe quel : ça vaut pour n'importe quel plugin. Si le plugin Agenda ou Formidable passe de la version X à X+1, en cassant de la compat, des boucles qui changent, etc, alors d'après cette argumentation ça voudrait dire qu'il faudrait faire un autre plugin avec un autre préfixe pour chaque. Pourtant ce n'est pas ce qu'on fait, et il ne faut pas faire ça.
Je crois qu'à peu près tout le monde est d'accord pour dire qu'il y a des problèmes importants d'ergonomie dans SVP. Il y a même un ticket explicitement sur ce point :
https://core.spip.net/issues/3017
Et deux autres sur l'ergo de SVP sur d'autres points (le sous-menu et le lien de configuration) :
https://core.spip.net/issues/3603
https://core.spip.net/issues/4429
Et j'ai travaillé une maquette ergo regroupant les solutions aux trois tickets à la fois, la dernière version (avec l'ajout de tcharlss) étant celle là :
https://core.spip.net/attachments/download/1179/3603.html
Cette ergonomie empêchant totalement de faire des mises à jour majeure sans le savoir. Tout est explicite.
Mais c'est de l'ergo… ensuite il faut faire une PR.
J'ai l'impression qu'avec ces polices, ou avec bootstrap peut être, et d'autres sûrement, la notion de "nouvelle version principale" est un peu différente de cette même notion quand il s'agit d'un plugin fonctionnel.
Les saisies en sont à leur version x=3 mais elles font toujours la même chose, de même que les crayons qui en sont à leur version 2.
Pour ces plugins fonctionnels, "mettre à jour", c'est bénéficier d'un fonctionnement amélioré et de nouvelles fonctionnalités, mais le service rendu est le même pour ce que existe déjà,
et d'ailleurs, je n'ai pas souvenir davoir rencontré des incompatibilités significatives lors des upgrades.
Bien sur il pourrait y avoir des incompatibilité si j'ai bidouillé un peu trop profondément l'usage
mais pas vraiment en général, du moins si je suis resté dans un usage banal.
Alors qu'avec bootstrap ou ces polices, ce sont des versions très différentes,
un peu comme si c'était des plugins différents.
JL
Je complète car j'ai pas été au bout.
J'ai l'impression qu'avec ces polices, ou avec bootstrap peut être, et d'autres sûrement, la notion de "nouvelle version principale" est un peu différente de cette même notion quand il s'agit d'un plugin fonctionnel.
Les saisies en sont à leur version x=3 mais elles font toujours la même chose, de même que les crayons qui en sont à leur version 2.
Pour ces plugins fonctionnels, "mettre à jour", c'est bénéficier d'un fonctionnement amélioré et de nouvelles fonctionnalités, mais le service rendu est le même pour ce que existe déjà,
et d'ailleurs, je n'ai pas souvenir davoir rencontré des incompatibilités significatives lors des upgrades.
Bien sur il pourrait y avoir des incompatibilité si j'ai bidouillé un peu trop profondément l'usage
mais pas vraiment en général, du moins si je suis resté dans un usage banal.Alors qu'avec bootstrap ou ces polices, ce sont des versions très différentes,
Et surtout : ces différentes versions en "x" ne traduisent pas absolument un "progrès".
Car la version 3 des saisies est "mieux" que la 2,
et donc on peut supposer qu'il faudra "nécessairement" y passer un jour ou l'autre,
alors qu'avec bootstrap ou ces polices, on peut supposer qu'on veuille durablement rester dessus,
en juste corrigeant les problèmes ou en intégrant les améliorations.
Chacune des nouvelles versions de ces plugins est un peu comme un fork du précédent,
qui ne l'invalide pas.
un peu comme si c'était des plugins différents.
Disais-je donc.
Car en effet il semble que SVP ne prend pas très bien cette éventualité
et que pour faire avec, il est plus simple d'en faire des plugins différents.
JL
Bonjour tout le monde,
Maquette effectivement très claire et efficace !
Beau travail.
Cordialement,
françois
Comme n'importe quel plugin, ça vaut pour absolument n'importe quelle fonctionnalité, je maintiens. Si les Saisies de Saisies 1 te suffisent et que tu n'utilises que #SAISIE, tu peux très bien rester durablement sur une vieille version si ça t'amuses aussi.
Et inversement pour BS, FA, etc, il te manque des icônes, et tu dois passer à une version supérieure (tout comme tu voudrais passer à une version supérieure de Saisies parce que des nouvelles saisies te sont utiles).
Ya vraiment aucune différence avec les fonctionnalités de n'importe quel autre plugin. Le fait que ça casse (par ex les préfixes des icônes changent de FA-4 à FA-5) c'est un choix des mainteneurs, mais ils pouvaient très bien choisir aussi de garder la compat ascendante. Tout comme dans un plugin SPIP c'est totalement un choix, et pas du tout un fait assuré, que quand tu mets à jour ça ne casse presque rien. Certains plugins, suivant les devs, peuvent parfaitement décider de casser beaucoup de choses en changeant X.
Donc bah non, je ne vois toujours pas de différence entre ces embarquements de libs externes, et des plugins internes à SPIP. Ça devrait être des branches changeant X : semver sert très exactement à ça.
Et améliorer SVP, tout le monde est d'accord là-dessus, cf la prop d'ergo à implémenter.
Si on a un problème ergonomique avec SVP quand il gère et prévient les gens des mises à jour : c'est ça qu'il faudrait corriger absolument, pas faire un préfixe par version majeur de plugin, non ?
Dans la mesure où SVP a un bouton "Cocher toutes les mises à jour", et un comportement identique quel que soit les risques de la mise à jour, je trouve que le choix de changer de préfixe est tout à fait cohérent.
Tu réponds ça en citant très exactement la phrase qui explique bien que c'est justement ÇA qu'il faut corriger…
> Je crois qu'à peu près tout le monde est d'accord pour dire qu'il y a des problèmes importants d'ergonomie dans SVP.
> Il y a même un ticket explicitement sur ce point :
> https://core.spip.net/issues/3017
Donc il faut améliorer SVP.
Et ta maquette est super.
Mais en attendant que ça soit codé,
les utilisateurs ont parfois besoin de mettre à jour un plugin SANS up le X
-- ce que ne permet pas SVP dans son état actuel.
Créer un nouveau plugin, avec un nouveau préfixe donc,
répond au besoin réel de ces utilisateurs dans l'état actuel réel de SVP.
Sinon que leur proposes tu ?
Garder leur vieille version ?
Suivre manuellement les annonces de nouvelle version et up par FTP ?
JL