Semver et surcharges de fichiers du noyau

Équipes maintenance
#1

En suivant de mieux en mieux Semver, se pose une question qui est un peu propre à SPIP (en tout cas plus rare ailleurs) : le fait que presque tout utilise le Path, et que SPIP permet de surcharger quasiment tous les fichiers, PHP ou squelettes.

La question étant : qu’est-ce qu’on considère comme relevant des choses à ne PAS casser quand l’équipe @maintenance choisit quoi mettre dans une version Y+1 ?

Ma position actuelle pour l’instant : il me semble que seules les utilisations de fonctions API PHP documentées ou très connues, ainsi que les inclusions de squelettes documentés, sont à prendre en compte dans les choses qui ne doivent pas être cassées quand on met à jour en Y+1.

En revanche, quand on décide de surcharger des fichiers entiers de fonctionnalités majeures du core (filtres.php, texte.php, image_truc.php, ou des squelettes importants de l’admin), pour y faire des modifications personnelles de son côté, alors cela ne relève pas d’une utilisation des API. C’est à l’inverse un choix de remplacement de fichiers à faire en connaissance de cause, et c’est à charge de la personne de maintenir sa surcharge dans le temps. Il est impossible de prévoir tout ce qu’on peut faire en surcharge, vu que c’est littéralement du remplacement de morceaux entiers de SPIP, c’est infini, donc ça ne peut pas être pris en compte.

Ainsi il est possible de faire des modifications dans des Y+1 qui changent des choses dans le PHP ou les squelettes, tant que ça ne casse pas les appels finaux, qui correspondent aux devs/intégrateurices. Mais pas à celleux qui surchargent les fichiers.

Un exemple concret d’une PR qui ne casse pas l’utilisation finale (en tout cas c’est le but), mais qui modifie le comportement pour les quelques personnes qui auraient surchargé un squelette central de l’API editer_liens :

#2

Là comme cela

  1. Effectivement pour moi les surcharges sont hors semver (autrement dit : un plugin qui surcharge doit mettre une version y max) d’un point de vue purement théorique (car la surcharge c’est par définition non fiable dans le temps)
  2. pour autant dans le cas d’espèce, comme le fait remarque @cedric, il n’y a pas que le mécanisme de surcharge, il y aussi le mecanisme de pipeline
  3. Et donc on pourrait dire : ah bah on fait de l’exception au semver pour surcharge + pipeline
  4. mais du coup où s’arrête les exceptions, ca rend les choses plus complexe etc

Et donc : je serais pour dire que surcharge/pipeline etc on reste sur du semver. Autrement dit : une fonction, qu’elle soit destinés à être passé à une autre fonction ou à un squelette, doit avoir sa signature et ses retours stables entre 2 incrément de y.

#3

Il me semble au contraire que surcharge et pipeline n’ont rien à voir. Un pipeline est conçu pour étendre « à l’infini » (X plugins peuvent ajouter à la suite dedans) sans rien casser, ET ça attend des informations documentées en entrée, ET ça fait totalement partie des API de choses « à utiliser » !

Donc pour moi les pipelines c’est exactement comme utiliser une fonction documentée, ni plus ni moins. Et ça n’a donc rien à voir avec surcharger un fichier entier.

Là pour la PR en exemple c’est effectivement pas un bon exemple (et donc faut pas se baser dessus) car ça va ensuite dans un pipeline. Mais par contre ça n’empêche en rien de statuer ensemble sur le cas spécifique des surcharges de fichiers qui elles ne devraient pas (pour moi comme pour toi) être pris en compte dans semver. Autrement dit on ne s’empêche pas de faire des modifications en Y+1 si ya seulement « ah mais celleux qui ont surchargé ce fichier ça va pas aller », tant que ça ne casse rien aux utilisations finales (mais pour les pipelines là oui)

#4

Alors oui, mais du coup la question concerne quoi / quand ? dans quel cas on a des surcharges possible de fichier qui ne concerneraient pas aussi des pipelines. Des cas de micro appel via recuperer_fond à un sous squelette du privé qui ne serait pas un formulaire (puisque dans ce cas on a un pipeline) ? et quid du pipeline afficher_final?

1 « J'aime »
#5

Pour rappel, ce fil a été ouvert suite à cet échange Draft: fix: on considère que le formulaire d'édition de lien est éditable à partir du... (!5940) · Requêtes de fusion · spip / spip · GitLab et le sujet a de nouveau été abordé ici Utiliser les propriétés logiques dans les CSS (!6003) · Requêtes de fusion · spip / spip · GitLab

Je cite ce que j’y disais ce matin :

Amha une surcharge d’un fichier situé dans ecrire ou prive est à « assumer » par la personne qui le fait. Sans quoi, puisque presque tout est surchargeable dans SPIP, on devrait sortir une version X à chaque modification d’un fichier situé dans ces répertoires.

1 « J'aime »
#6

Comme on peut voir cela initialement, je suis plutot aussi sur cette ligne. Reste donc à dire explicitement dans les explications sur le semver (peut être un article sur spip.net) que cela ne concerne pas les fichiers du core. Et qui du du rapport aux pipelines / des paramètres passés à l’appel des fichiers (cf origine du fil)