[spip-dev] r20140 - spip/prive/formulaires

Dev
1

Merci beaucoup pour ce correctif, Matthieu, qui résout le problème, même si trouver l'option n'est pas si intuitif qu'avec SPIP 2. (Je veux dire il n'est pas intuitif de devoir cliquer sur un lien « changer » situé à côté du nom de la langue de l'article pour pouvoir lier/délier l'article comme une traduction.)

Maintenant la question : quand est-ce qu'il va être incorporé dans une version stable de SPIP, pour qu'on puisse l'utiliser ?

Autrefois, je suivais SPIP de beaucoup plus près, et quand il y avait un correctif comme celui-ci, je n'hésitais pas à faire tourner le site avec la version SVN. En fait notr site a utilisé la version SVN-dev pour la plus grande partie de son histoire. Mais maintenant avec SPIP 3, je trouve que je ne peux plus faire cela à cause des 18 plugins utilisés qui ne vont pas tous tourner avec une version SVN.

Bien sûr, on a fait beaucoup de progrès. Je remarque pourtant une certaine perte pour ce qui concerne ma faible participation à SPIP. Si j'ai contribué quelque chose, c'etait surtout en remarquant des bugs. Maintenant que je ne peux plus tourner la version SVN en production je remarque pratiquement plus de bugs, et même quand je les vois, comme je sais que c'est seulement avec la prochaine version stable que cela marchera pour nous, je les remonte moins vite ...

Aïe, je commence à parler trop negativement. Je m'excuse.

encore une fois merci, Paolo

2

Bien dès qu'une version satisfaisante sera trouvée pour ce correctif je le reporterais.

À te lire j'ai l'impression que c'est pas encore au point tout à fait.

Je comprends aussi que la logique «changer» pour pouvoir délier ou lier n'est pas des plus évidentes. En même temps, ce sont des actions extrêmement rares normalement (tu le fais une fois et c'est tout, voire tu n'as pas à le faire) et donc ça me gène aussi d'avoir ces boutons en permanence visibles.

As tu une idée pour cela ?

MM.

3

« Ecrire une nouvelle traduction » est aussi assez rare, n'est-ce pas ? En SPIP 2 les deux choses étaient cachées (voir png attachés). Et le tout était plus clair (au moins pour le cas sans menu de langue).

Paolo

Trad2.png

Trad1.png

4

Oui, au delà du point précis des traductions, tu poses un problème dans notre manière de développer.

Désormais, il n'y a plus que deux niveaux :
- la version stable, vraiment stable
- et la version dev, vraiment dev et où la plupart des plugins ne s'activent plus

C'est probablement mieux cadré qu'avant où trop de gens étaient en prod sur une version dev ! Mais n'empêche que du coup, il n'y a plus cet aspect progressif...

Une des causes à mon avis, c'est qu'on a fait effectivement ce choix de plus grande séparation stable/dev mais SANS pour autant qu'il y ait un cycle de développement plus rapide !

Du coup ça n'a pas vraiment de sens : on se retrouve avec la même version stable pendant trop de temps. Est-ce vraiment mieux que l'ancien système où la version dev était plus facilement utilisable en prod ?

Je suis toujours convaincu que c'est mieux de séparer, mais dans ce cas là il faudrait peut-être des choses intermédiaires ? Genre la branche de dev qui est vraiment inutilisable en prod, mais des versions "beta" qui arrivent plus rapidement, même s'il n'y a pas des milliards de changements dessus. Une beta 3.1 et le trunk en 3.2 quoi. Un truc plus progressif.

Le problème qui se pose, c'est que là on a un système avec les plugins qui est vraiment trop contraignant : quand on change une version fonctionnelle (3.0.X à 3.1.0) qui n'est *rien censé casser de grave* et bien pourtant il va falloir repasser sur TOUS les plugins de spip-zone pour rechanger leur XML !

C'est pas viable à long terme si on est réellement censé avoir un rythme plus rapide pour le noyau (ce qui n'est pas le cas actuellement, on est d'accord). Faire des tests de compat sur des dizaines de plugins, ça va quand on change de version majeure, mais pour le chiffre du milieu...

Comme le Matthieu sur IRC à l'instant : il ne s'est pas passé grand chose sur la 3.1 pour l'instant. Mais il suffit qu'il y ait une chose intéressante qui arrive (même pas énorme, du moment que ce n'est pas une simple correction de bug), pour que ça vaille le coup d'avancer. Et du coup on se retrouve avec le problème des milliards (:D) de plugins à devoir changer le XML.

À minima il faudrait une option très facile à activer, pour tous les Paolo qui veulent tester les versions devs, au moins pour les non-majeures qui ne cassent pas grand chose.

5

Je comprends aussi que la logique «changer» pour pouvoir délier ou
lier n'est
pas des plus évidentes. En même temps, ce sont des actions extrêmement
rares
normalement (tu le fais une fois et c'est tout, voire tu n'as pas à le
faire) et
donc ça me gène aussi d'avoir ces boutons en permanence visibles.

As tu une idée pour cela ?

« Ecrire une nouvelle traduction » est aussi assez rare, n'est-ce pas ?

Jes, vi pravas !
Effectivement, lui il est là tout le temps maintenant.

En SPIP 2 les deux choses étaient cachées (voir png attachés). Et le
tout était plus clair (au moins pour le cas sans menu de langue).

De ce que j'ai compris, les machins qui se font «au survol» c'est pas terrible pour les tablettes et autres téléphones qui utilisent des gros doigts qui cliquent.

Je n'ai pas de solution idéale à proposer alors pour l'instant, alors on va dire que ça va rester comme ça : il faut cliquer «changer» pour avoir accès au bouton «délier l'article des traductions» ou «traduction de l'article x».

Par ailleurs, j'ai corrigé quelques glitch que j'ai vu depuis, par http://core.spip.org/projects/spip/repository/revisions/20144

MM.

6

[...]

Désormais, il n'y a plus que deux niveaux :
- la version stable, vraiment stable
- et la version dev, vraiment dev et où la plupart des plugins ne
s'activent plus

Oui, enfin, la 3.1-dev n'a rien de changée actuellement fondamentalement de mémoire, hormis des corrections de notices PHP et du phpdoc. Actuellement on pourrait presque dire qu'elle est plus stable que la 3.0 :slight_smile: Mais l'idée c'est bien d'y faire des développements pour ceux qui en ont à faire. Il ne s'est juste rien passé dessus encore.

Ceci dit, c'est vrai, et je trouve aussi cela ennuyant, c'est que les plugins ne peuvent s'activer dessus par défaut. En même temps, on peut dire que c'est un processus des plus sages : celui qui joue avec la version de développement doit de lui-même autoriser de passer outre cette contrainte en mettant dans mes_options :

define('_DEV_PLUGINS', '3.1.99');

Cela indique que tous les plugins sont alors compatibles avec cette version et permet de les tester.

Mais à la sortie (ou avant) la 3.1, il va falloir repasser derrière tous les plugins pour monter leur compatibilité. Sur la zone ça va être facile. C'est juste pour les plugins hors sols que certains vont avoir des surprises lors de la mise à jour de leur SPIP.

Donc oui, je suis partagé sur ce détail. Ceci dit ça montre que le critère «compatibilité» des paquet.xml fonctionne très bien :slight_smile:

Pour certains plugins on pourrait certainement mettre [3.0;3.*] sans autres préoccupations. Ce qui résoudrait ce problème pour la plupart, qui utilisent les points d'API correctement.

[...]

À minima il faudrait une option très facile à activer

Bah c'est déjà le cas, comme cité au dessus il me semble ?

MM.

7

Est-ce que du coup ça ne pose pas la question de la numérotation de SPIP lui-même ?

Pour les plugins, il est posé la règle suivante. Avec une numérotation x.y.z : on incrémente z si correction de bug, y si ajout de fonctionnalité et x si incompatibilité. Si la version de dev produit une incompatibilité, ne devrait-elle pas être nommée version 4 et non version 3.1 ? Et si une incompatibilité n’apparait que sur un changement de x, les plugins ne devrait-il pas donner une borne supérieur sur x et non x.y ?

Firefox a changé à un moment donné sa numérotation, avec du coup un changement majeur du numéro de version de manière plus fréquente.

Enfin, le core a été découpé en plusieurs plugins. Pourrait-on envisager qu’il soit possible de mettre à jour les extensions via des Zip autonomes ? (ou pour ceux d’ailleurs qui déplacent ces plugins de plugins-dist à plugins/auto)
Ou alors, que faire si le core n’évolue que peu mais qu’il y a des corrections dans les plugins-dist ? Faut-il attendre une nouvelle version du core impérativement ?

8

Est-ce que du coup ça ne pose pas la question de la numérotation de SPIP
lui-même ?

Pour les plugins, il est posé la règle suivante. Avec une numérotation
x.y.z : on incrémente z si correction de bug, y si ajout de fonctionnalité
et x si incompatibilité. Si la version de dev produit une incompatibilité,
ne devrait-elle pas être nommée version 4 et non version 3.1 ? Et si une
incompatibilité n'apparait que sur un changement de x, les plugins ne
devrait-il pas donner une borne supérieur sur x et non x.y ?

C'est le principe de "semantic versioning" utilisé depuis longtemps par la
plupart des projets libres : http://semver.org/

9

ok ok : il faut être moderne et suivre les technologies.
cela dit : utiliser le privé pour sélectionner ou rédiger une traduction, y'a beaucoup de monde qui fait ça depuis son smartphone ?
sans dec ?

#JusteJeMePoseLaQuestion

10

Depuis une tablette, de plus en plus (apparemment, on ouïe dire qu'un nombre croissant de gens n'a plus d'ordinateur bureau ou portable, mais travaille directement sur tablette surtout lorsqu'il s'agit de rédactionnel : mails, bureautique, blog, etc).

Et sur une tablette non plus il n'y a pas de "hover".