On voit bien qu’il est très difficile de satisfaire tout le monde.
Je suis évidemment favorable à ce que tu proposes, mais il faut aussi réussir à fluidifier encore la création de releases. Là ça va fonctionner tant que 3 personnes (en gros) sont toujours suffisamment motivées à ça (s’occuper des branches, changelog, reports & adaptations, et faire les releases…) ; je te cache pas que ça prend du temps (pas mal même ce début de passage à 4.3), et que c’est aussi du temps qui n’est pas utilisé à faire avancer la transformation de la 5.0.
Cela dit j’ai espoir que ça puisse améliorer la motivation des participant·es qui peuvent continuer d’apporter des améliorations dans la branche 4.x du coup, et qu’on peut peut être aussi faire des reports qui faciliteraient le passage à SPIP 5 (tu me parlais en PV de mettre les composer.json des plugins-dist par exemple dans la 4.3, qui serait une petite étape de franchie)
Comme je l’ai dit maintes fois, ça me va bien des versions Y tous les 6 mois, même si elles n’ont pas de super feature de la mort qui tue dedans, à partir du moment où on n’a pas à recréer autant de branches sur les plugins-dist à chaque fois (là j’ai tout passé par défaut en borne max 4.*, ce qui devrait éviter cela donc).
Mais comme ça dépend beaucoup de la motivation fluctuante de qq personnes, je crois qu’il faut réussir à dire que c’est une projection, un souhait, et que… peut être que ça évoluera encore.
Il faut qu’on arrive à garder de la joie à participer, tout en transformant assez radicalement la base structurelle du code de SPIP !