Je précise que mes scripts n’ont pas du tout vocation à être maintenus et exploités dans la durée. Ni publier…
C’était du one-shot, l’idée étant d’éclaircir la situation et de redonner la main aux contributeurices le plus vite possible …
- Il va y avoir des releases de SPIP au plus tard vendredi prochain, dont une
4.3-qqc
. J’espère que ce sera 4.3.0-beta
. Et j’espère qu’elle sera accompagnée d’un « code freeze ».
- Dans moins de 2 mois, la
4.3.0
« stable » devrait sortir et
- dans 8 mois environ, c’est la
4.4 LTS
qui arrivera.
- Bien que certain·e·s d’entre nous aient envie et confiance dans ce modèle, j’entends le manque de sérénité des autres.
- Pour autant, on sait que l’adoption d’une nouvelle version mineure dépend avant tout de la disponibilité de plugins compatibles.
Et je maintiens.
Pour autant, ce serait une bonne idée d’ajouter un critère d’éligibilité supplémentaire, les groupes GitLab.
À la relecture de cet échange, il semble admis que, bien que dans un seul et même groupe (spip-contrib-extensions
) principalement, chaque plugin à ses mainteneureuses spécifiques, ses règles, ses méthodes, son rythme.
Techniquement, ça veut dire que « des personnes » s’organisent différemment autour d’un ou plusieurs plugins, mais au même endroit (dans un groupe).
- Je pense que ces personnes y gagneraient à maintenir leurs plugins dans des groupes indépendants les uns des autres, en exposant leurs règles de contributions, notamment en matière de compatibilité SPIP, mais pas que.
- Les utilisateurs de ces plugins y verraient aussi plus clair.
- Les opérations de masses tels que l’archivage ou les mises à jours de compatibilité SPIP (et bien d’autres) seraient plus aisées aussi.
Concernant la mise à jour en masse des fichiers paquet.xml
des 530 et queqlues plugins compatibles 4.2.*
, je vous laisse poursuivre la réflexion, trouver un consensus entre vous, mais en l’état, j’aurais plutôt tendance à me ranger du coté de @maieul : « autant laisser les responsables faire elleux même le travail » …