casse l’API publique
C’est un peu fort et inquiétant non ?
bah c’est la définition. Ca casse l’API, pas forcément intégralement mais ca casse. Sinon ce serait pas un changement de X…
Oui mais c’est réducteur : il n’y a pas que de la casse mais aussi des nouveautés ; et comme tu le dis ça ne casse pas tout dans l’API. En plus, ces cassures concerneront plus les développeurs de plugins que les créateurs ou utilisateurs de squelettes. Et il ne faut pas dissuader à tort de mettre à jour.
Donc peut être plutôt « Un changement de X apporte des fonctionnalités importantes et peut casser certaines parties de l’API PHP publique »
J’ai modifié. Mais je rappelle juste qu’on demande aussi un texte « court ».
Désolé, je me mêle sûrement de ce qui ne me regarde pas.
Mais ce qui a motivé ma remarque c’'est que SPIP promet et promeut depuis le début une compatibilité ascendante.
Alors je sais très bien que ce ne sont que des mots, que ce n’est pas une promesse absolue, mais bon, « Casser l’API publique » ça parait un peu en contradiction avec cet état d’esprit.
C’est ce que je voulais dire.
Pour répondre à ton autre réponse, un texte peut employer des verbes moins secs (au hasard, « modifier » plutôt que « casser » ?) tout en restant court et compréhensible.
Mais ça dépend des intentions des mainteneurs, s’ils veulent casser ou modifier.
+1 une option serait d’utiliser cette formule de la doc semver « changements non rétrocompatibles »
Ho la belle pointe ^^ Je te rappelle que tu fais aussi partie de l’équipe de maintenance 
Disons qu’il y a une équilibre à trouver, pas facile, entre maintenir la compatibilité ascendante et réussir à faire évoluer le code pour répondre aux demandes et besoins sans se retrouver avec un sac de spaghetti à la fin. Donc il y a bien a certains moments où l’on est obligé de « casser » dans le sens où il faut que la personne fasse des adaptations. Mais les cassures ne sont pas franches. Mais je pense que si on ne parle pas de casser, d’une manière ou d’une autre, on ne rend pas justice à ce que le changement de x, et on se retrouve justement enfermés dans la confusion.
Ca ne veut pas dire que tout est cassé à chaque fois, mais uniquement certains élèments, lesquels sont décrits normalement désormais. Après on peut utiliser l’euphémisme « changement non retrocompatibles » (ce qui est d’ailleurs fait présentement).
Je veux dire par là que je viens de le faire.
1 « J'aime »
Juste un rappel : on utilise aussi conventional commits, dans lequel la notion de BREAKING CHANGE (en majuscule, parce que elle est spécifiée comme ça) existe bel et bien, même dans la version française …
BREAKING CHANGE: un commit qui contient dans son pied le mot-clé
BREAKING CHANGE:, ou dont le type/étendue est suffixé d’un!, introduit une rupture de compatibilité dans l’API (cela est en corrélation avecMAJORen gestion sémantique de versions). Un BREAKING CHANGE peut faire partie des commits de n’importe quel type.
Dans un cadre plus général de développement, on n’hésite pas à parler de « BC Break » (pour « backward compatible break ») .
Dans semver, la notion de backward compatible existe et est documentée.
Question : Comment allez-vous traduire ce nouvel article ? En inventant un vocabulaire particulier pour chaque langue, dont l’anglais ? Tout en faisant référence à des documents qui n’ont pas le même vocabulaire ? 
La communauté SPIP a, je pense, atteint un certain niveau de maturité qui me fait croire qu’elle n’est pas trop traumatisée par l’emploi de mots tels que break ou casse, dans un cadre technique. Arrêtons de nous cacher derrière nos petits doigts.
Et pour clore là-dessus, des BC Breaks, on en a fait quelques-uns depuis une douzaine d’annnées (SPIP3, puis 4). Et sans doute avant. Et parfois sur des patches (le z, hein) …
C’est vrai qu’on n’était bien loin d’être au top là dessus, c’est amha très bien qu’on se soit amélioré sur ce point
2 « J'aime »
C’était notre volonté commune de membres de la team @maintenance
Désolé, c’était mal formulé mais il n’y avait pas de cynisme, juste une inquiétude récurrente.
Oui, bon, ok, j’ai coché une case à un moment.
Mais à vrai dire je ne sais même plus où on peut voir qui fait partie de quoi.
My bad, mauvaise interprétation de ma part
Chaque équipe dispose d’un post de présentation avec un lien vers liste des membres de l’équipe cf About the maintenance category