Coucou 
On a 2 topics qui parlent de roadmap. L’un sur le « court terme » (celui-là), l’autre sur le « long terme » (celui-ci). Ils sont en commun de parler d’échéances, de dates prévisionnelles de sortie de telle ou telle version de SPIP. Je crois par contre que chaque personne qui s’implique dans cette histoire interprète les « termes » avec une grille de temps personnelle.
J’ai le sentiment que personne ne conteste aujourd’hui le fait que nous annoncions des dates de sortie pour de futures versions. Comme les réactions à ces annonces se produisent sur plusieurs canaux (irc, discuter, autre?), et dans des temps différents, c’est pratiquement impossible d’en déduire une « moyenne » ou un consensus quant au délai acceptable entre 2 releases d’importance.
Bien sûr, il y a celleux qui ne s’expriment pas, soit parce qu’iels s’accommodent du rythme, peu importe les délais, soit parce qu’iels ne font plus de mise à jour… Toutefois, parmi les personnes qui s’expriment et en simplifiant un peu, on devine 2 tendances :
- celleux qui trouvent que ça va trop vite
- celleux qui trouvent que ça va pas assez vite
Je pense qu’on devrait chercher à faire converger ces deux tendances avant même de parler de numéros de version et de contenu. Les aménagements et les solutions techniques pourront peut-être en découler.
Pourquoi ça va pas assez vite ?
Je crois que @marcimat a très bien résumé la situation. Je n’ai pas plus à dire à titre personnel, j’adhère, mais il y a peut-être d’autres formes de ressentis.
Pourquoi ça va trop vite ?
Essentiellement, si j’ai bien compris, parce que les plugins ne sont pas rendus compatible avant une sortie de SPIP, mais après, une fois qu’elle sort. Mais aussi en raison du support des versions PHP. Il me semble d’ailleurs que ça devient de plus en plus la raison principale…
So what ?
J’ai parlé sur IRC il y a quelques jours de la notion de « cycle de vie » et je pense que c’est la notion qui nous manque.
Nous ne nous contentons pas de sortir des versions stables. Nous annonçons des durées de vie de ces versions. Nous annonçons aussi des versions alpha et/ou beta. C’est en général, dans d’autres projets logiciels, le moment où les utilisateurs testent, mais surtout préparent, leur propres projets à la compatibilité avec la version à venir.
Dans le cadre de SPIP, un projet n’est pas seulement un ou des sites, mais aussi un ou des plugins. Et c’est peut-être là où le bas blesse :
- Peut-être aurait-il fallu mieux expliquer à quoi ses alphas/betas sont sensées servir ?
- Nous proposons peut-être un délai trop court entres ces « pre-releases » et les releases stables ?
- Les mécanismes de gestions de dépendances entre spip et un plugin sont-ils suffisants pour faire ce genre de tests et de préparation ?
- Accessoirement, on peut facilement déterminer qui sont celleux qui maintiennent encore SPIP à ce jour, mais c’est beaucoup plus flou pour déterminer qui maintient un plugin. Vu que c’est « tout le monde », il se peut qu’en fait, ce ne soit personne…
- Enfin, petite touche personnelle, nous n’utilisons pas de mécanismes automatiques qui permettraient de tester et de rapporter les problèmes éventuels de compatibilité. Mais c’est lié aux points ci-dessus, j’imagine.
On a donc tout ça à clarifier : quels moyens ont (ou n’ont pas) les mainteneureuses de plugins pour préparer la compatibilité de leur projet avant la sortie d’une version stable ? quel est le temps nécessaire/acceptable à donner avant une resease stable ? quel est le temps de développement souhaité par celleux qui souhaitent faire évoluer le coeur de spip (avant de livrer une alpha/beta donc) ?