Ceci devrait répondre à ta question 
Techniquement, cela ne changerait rien pour les personnes qui installent SPIP avec spip_loader ou à partir du zip, et les outils qui permettent aux devs de récupérer SPIP en git prendraient en charge automatiquement l’étape
composer installcf https://git.spip.net/spip-contrib-outils/checkout/pulls/6
d’autant plus qu’une bonne partie (la majorité ?) des utilisateurs qui récupèrent SPIP en git le font via checkout ou spip-cli, cad avec déja du Composer « dans le moteur »…
Qu’en pensez-vous ? On merge, on ne merge pas ?
oui ! 
1 « J'aime »
Je suis aussi favorable à la fusion, surtout si c’est transparent
Pour info, puisque tout est permis le vendredi (non ?), c’est enfin intégré \o/
3 « J'aime »
Coucou, faute de disponibilité de @marcimat et ma part on a pris du retard pour la release des pré-versions de la 4.2 ce qui nous oblige à revoir le calendrier.
Si ça vous va , je propose de décaler tout ça ainsi :
- sortie d’une pré-version de la 4.2 (alpha+beta, ou uniquement une RC) au 10 janvier 2023
- sortie de la version stable de la 4.2 au 10 février 2023
- décalage des dates de fin de support actif et sécu des autres versions en conséquence
Ce qui donne le diff suivant pour le fichier data/releases.json · master · James / supported-versions · GitLab
diff --git a/data/releases.json b/data/releases.json
index df824b7..cdb572a 100644
--- a/data/releases.json
+++ b/data/releases.json
@@ -2463,7 +2463,7 @@
"branch": "3.2",
"initial_release": "2017-10-12 09:13:02",
"active_support": "2021-07-09",
- "eol": "2022-12-31",
+ "eol": "2023-02-10",
"last_version_release": "3.2.16",
"last_date_release": "2022-07-21 11:55:58",
"technologies": {
@@ -2804,7 +2804,7 @@
"branch": "4.0",
"initial_release": "2021-07-08",
"active_support": "2022-03-31",
- "eol": "2022-12-31",
+ "eol": "2023-02-10",
"last_version_release": "4.0.8",
"last_date_release": "2022-07-21 11:44:26",
"technologies": {
@@ -3019,8 +3019,8 @@
{
"branch": "4.1",
"initial_release": "2022-03-25",
- "active_support": "2022-12-31",
- "eol": "2023-06-01",
+ "active_support": "2023-02-10",
+ "eol": "2023-08-10",
"last_version_release": "4.1.5",
"last_date_release": "2022-07-21 17:39:45",
"technologies": {
@@ -3191,9 +3191,9 @@
},
{
"branch": "4.2",
- "initial_release": "2022-11-30",
- "active_support": "2023-05-31",
- "eol": "2024-12-31",
+ "initial_release": "2023-02-10",
+ "active_support": "2023-07-10",
+ "eol": "2025-02-10",
"last_version_release": "",
"last_date_release": "",
"technologies": {
@@ -3260,8 +3260,8 @@
},
{
"branch": "4.3",
- "initial_release": "2023-06-01",
- "active_support": "2023-12-01",
+ "initial_release": "2023-07-11",
+ "active_support": "2024-01-10",
"eol": "",
"last_version_release": "",
"last_date_release": "",
@@ -3294,7 +3294,7 @@
},
{
"branch": "5.0",
- "initial_release": "2023-12-01",
+ "initial_release": "2024-01-10",
"active_support": "",
"eol": "",
"last_version_release": "",
2 « J'aime »
Oui. Décalons les dates pour releaser tranquillement et sortir une belle SPIP 4.2
Compte tenu du temps qu’il a fallu pour déclarer/adapter les plugins à SPIP 4.1, je m’interroge sur la pertinence de 2 releases par an.
Déjà, une par an, c’est chaud pour suivre (rendu cependant nécessaire par le rythme de PHP).
Mais 2…
À moins :
- de changer la manière dont la compatibilité des plugins est gérée (genre à la WP : n’a pas été testé, mais on peut installer à ses risques et périls)
- ou de faire conjointement aux ruptures de compatibilité une branche à merger pour chaque plugin touché par cette rupture (on peut rêver, hein…)
1 « J'aime »
Pour info, j’ai mergé « en accord avec moi même » sans quoi la page de download était pétée sur spip.net cf Impossible de télécharger le zip de SPIP depuis spip.net
On aura tout le temps d’affiner les dates par la suite…
1 « J'aime »
Et je complète :
- avoir une page par nouvelle version qui liste les changements pouvant casser un plugin : changement de path et/ou de nom d’un include, changement de nom d’une fonction, disparition d’un define…
- avec idéalement un grep des plugins/squelettes concernés (et mis à jour régulièrement)
- et aussi les incompatibilités avec les nouvelles versions de PHP (rektor ?)
Dotclear qui a les mêmes problématiques a fait ça : Adapter son code pour la 2.24 › Blog Dotclear › Dotclear › Prenez le contrôle de votre blog
un changelog ? ^^
Le changelog contient toutes les modications, et pas forcément seulement celles ayant des conséquences possibles, et pas toujours le détail de la disparition d’un define…
J’insiste, mais on suit bien conventionnal commit et keepachangelog, donc c’est bien les parties changed, deprecated & remove qui t’intéressent (bref, je vais pas refaire l’histoire de tout ça).
1 « J'aime »
Merci @b_b pour cette indication.
Mais, je viens de tomber sur la disparition de _RACCOURCI_LIEN qui n’est pas listée dans changelog.md
La ligne concernée est sans doute
- #5321 Refactoring de la collecte et echappement des liens
Oui il y pas mal de constante sur les raccourcis qui ont sauté et faut rehcercher manuellement dans l’historique pour savoir quel commit a fait quoi et comment.
1 « J'aime »
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.
4 « J'aime »
Je ne sais pas dans quelle mesure cela aurait été délicat de conserver ces constantes en ajoutant un dockblock @deprecated, ce qui est la moins mauvaise des méthodes pour ça entre deux versions mineures (4.1->4.2)
Alors pour ma part, et pour éviter tout malentendu : non la direction prise en ce moment est bonne, très bonne même. Et bravo à la petite équipe qui s’y colle patiemment.
Les quelques points de rupture de compat lié a du vieux codes ne sont que des broutilles par rapport à cela, et qui se résolvent facilement.
Merci encore et bravo.
1 « J'aime »
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.
Cette direction convient et est la seule possible pour assurer une pérennité de notre œuvre collective car oui, il faut avancer en simplifiant notre écosystème et nos pratiques car depuis les dernières SPIP Party auxquelles j’ai participé, je n’ai toujours pas vu la refonte de la documentation qui motivait pleins de gens à l’époque…
Donc je dis encore bravo à ceux qui ont permis de sortir cette version 4.2 et je m’en vais poster sur le long terme .