Calmons-nous sur les sauts de versions des plugins :)

[b_b]

Salut, je rebondis sur ce commit dans le plugin GIS :

gis

Ça n’est pas pour blâmer @tofulm mais juste pour faire une remarque sur la « méthode ».

Je pense qu’il n’est pas utile/bon, d’envoyer des commits qui patchent un micro bug et qui en même temps changent la version du plugin dans le paquet, d’autant plus que c’est fait direct dans la branche master. D’autant plus que le plugin n’a pas été tagué dans la foulée, donc le changement de version ne sera pas visible pour les gens qui passent par SVP.

Amha, c’est une mauvaise pratique qu’on a hérité de l’époque SVN, mais maintenant qu’on est sous GIT on peut faire les choses plus proprement.

Perso, j’ai des PRs en attente, et si le dernier commit entre en conflit avec celle-ci, c’est moi qui prendre les effets de bords. De plus, j’ai envoyé des modifs ces derniers jours, sans taguer le plugin volontairement car je comptais releaser une fois tout ça au propre.

Je pense qu’il faudrait mettre à jour et compléter nos « règles de collaboration » pour la zone en y indiquant qu’il faut :

• privilégier les PRs, même si c’est pour petite modif ; c’est toujours mieux, ça permet de discuter avant de balancer dans le master et ça permet la relecture par les autres membres de la zone
• ne jamais changer le numéro de version dans le même commit qu’un patch ; la release d’un plugin est un travail d’équipe ou alors elle incombe aux principales personnes qui maintiennent le plugin en question, bref ça se discute.

Au plaisir de lire vos avis et remarques sur la question

[tofulm]

Désolé b_b,
je pensais que c’était une petite modif qui corrigeait simplement un warning et donc que je pouvais me passer de faire une PR.
Sur un autre plugin de la zone, pour faire le même type de correction, j’avais fait une PR. On (je ne me souviens plus de qui) m’avait dit que ce n’était pas nécessaire pour ce type de correction.
Concernant le changement de numéro de version, Ok, c’est noté ! Veux tu que je corrige ?

Je partage complètement ton avis sur la mise à jour de nos « règles de collaboration » ! Je ne sais jamais ce que je dois faire

[marcimat (Matthieu Marcillaud)]

Oui, rappelons surtout qu’un commit n’a pas vocation à incrémenter systématiquement un numéro de version de plugin.

Enfin, en passant, dans SPIP on va essayer de mettre en place un CHANGELOG.md de type Tenez un Changelog et il pourrait être opportun de faire pareil pour les plugins. (ne renseigner que les trucs pertinents, et avoir une entrée [Unreleased] tant qu’une nouvelle version n’est pas créée.

[b_b]

Pas de problème mignon

Comme je le disais je ne souhaitais pas te blâmer, mais uniquement signaler qu’il faut revoie nos méthodes de travail de groupe.

À ce sujet, je ne retrouve plus trace de ce qu’on avait rédigé à ce sujet sur contrib ou ailleurs ? Quelqu’un s’en souvient ?

En cherchant ça, je remarque que notre charte d’accueil Charte d’accueil de SPIP - SPIP mentionne encore un lien vers Aperçu - SPIP - SPIP Core (Forge de développement) pour « notre outil de tickets ». Il y aurait une personne motivée pour corriger ça ?