Je suis d’accord : il est toujours possible de mieux faire.
Question alors : qui le fait ?
Je vais dire les choses autrement : on ne peut pas gérer à 3 ou 4 l’ensemble de l’écosystème SPIP actuellement. On s’y épuise, réellement, ou on manque de temps. Une release, c’est plein de choses à prendre en compte, dont la mise à jour des sites de la Galaxie, des tests, des vérifications, de la doc… pendant que le monde PHP évolue lui-aussi.
À chaque fois qu’on utilise des outils ou usages spécifiques à SPIP (tests unitaires qui étaient spécifiques, Coding standards spécifiques, répertoires spécifiques, pas de Composer, outils de releases spécifiques…), on se rajoute un travail de suivi, on rame pour trouver du temps libre pour s’en occuper.
Systématiquement on nous a reproché un manque de documentation, c’est juste. On met en place code.spip.net, programmer.spip.net en plus des nouveautés sur spip.net : ce n’est pas suffisant, et pour Programmer d’ailleurs, ce n’est plus vraiment à jour certainement, comme beaucoup de pages de SPIP.net qui mériteraient un relifting… Mais ça nécessite du temps, beaucoup, des gens, de la connaissance de SPIP…
On a essayé de produire un CHANGELOG.md dans un format relativement standard, on a essayé de le remplir correctement. Il faut passer derrière chaque PR pour l’ajouter ou le demander à l’auteur ou autrice, puisque visiblement seul @b_b ou moi qui le mettons par défaut, cela crée d’autres contraintes lors de la création de PR (cette nouvelle complexité agace les auteurs ou autrices) et lors des reports (et on doit améliorer ce point), mais il nous a semblé que c’était important. Il y a évidemment des manques. Il y a des améliorations à apporter, c’est certain.
Il y a peut être aussi, puisque tu parles de _RACCOURCI_LIEN, un usage à l’extérieur de SPIP de définitions qui étaient internes au core SPIP. Historiquement SPIP n’indique pas, ou rarement, ce qui est public de ce qui est private pour ces constantes et autres fonctions… Le fait que des éléments censés être internes disparaissent (je n’ai pas vérifié ce cas précis), n’est pas vraiment en théorie problématique.
Mais bon, on a eu très peu de retours sur SPIP 4.2.0-alpha — On a des retours juste maintenant depuis que la 4.2.0 est sortie. Et dans l’ensemble ça se passe très bien d’ailleurs semble t’il heureusement.
Bref, avec les énergies présentes actuellement, nous n’avons pas (de mon point de vue en tout cas) les moyens ni humains ni temporels de gérer autant de spécificités, de sites de Galaxie différents. De mon point de vue, tout ce qui peut aller vers une standardisation des pratiques avec ce qui se fait habituellement dans l’écosystème PHP est à prendre, et tout ce qu’on peut déléguer en terme d’outil et librairies est à prendre… même si ça doit rendre plus gros l’archive de SPIP (nombre de fichiers emportés plus conséquents)
Mais comme on dit, on ne peut pas être au four et au moulin, et qui plus est pour un projet libre sans financement direct (et c’est très bien), il est difficile de (nous) reprocher de faire ce qui nous anime le plus à un instant T, ce qui nous parait le plus pertinent. Et effectivement c’est rarement écrire de la doc en plus.
J’aimerais qu’on arrive à avoir grosso modo des trigger_error(..., E_USER_DEPRECATED); sur les éléments à chaque fois qu’on sait à l’avance que ça sera déprécié pour que ça apparaisse dans les logs. Cela dit, ce n’est pas évident avec le code actuel d’anticiper cela. Ça nécessite pas mal de rigueur et de volonté, parmi les autres choses à gérer.
On peut aussi laisser SPIP vivre «en l’état» et ne plus le modifier, de la sorte ça ne cassera jamais rien sur les sites existants. Pourquoi pas ? C’est à discuter aussi.
Je n’ai pour ma part, pas envie de m’échiner dessus. On trouve du plaisir et de la reconnaissance à créer une œuvre collective, d’utilité sociale et politique, à la maintenir au fil du temps, notamment entre copain·es, mais si personne n’y trouve plus son compte, qu’il y a trop de dissensus, de rancœurs ou je ne sais quoi, on ne va plus aller bien loin.
Si la direction qu’«on» prend ou souhaite prendre ne convient pas (standardiser, aller vers des dépendances via Composer, changer certains paradigmes de programmation), exprimez-le (et reprenez les choses en main). Parce que ça risque de casser des choses entre une version 4.2 et une version 5.0, si ça sort un jour.