Salut, je pense qu’il est temps de décaler la date de release de SPIP 5 cf Versions maintenues - SPIP
Elle est annoncée au 23 janvier 2024, amha on peut la repousser de 6 mois ou un an.
Edit : il serait aussi logique de décaler les dates de support actif/sécu des branches 4.1 et 4.2.
Vos avis ?
Oui cela me semble plus raisonnable 
Oui, on sent bien que ça manque de monde et de commits pour releaser une 5.0 en janvier. Repousser de 6 mois semble bien
Ya des gros chantiers ouverts pour la 5, et ya des gros chantiers de la 4 qui ne sont pas encore pleinement aboutis. Il serait certainement plus apprécié que les prochaines releases avancent vers la finition de ces chantiers plutôt que la date jadis prévue pour une version « 5 » soit respectée.
C’est pas faux, reste plus qu’à trouver des personnes « grassement » motivées…
Au delà de la liste individuelle des 337 (!) tickets ouverts pour 4.2, est ce qu’il y a une vue synthétique de ces gros chantiers ?
Quand on était sur redmine oui, car on avait des « meta tickets » genre #3719 - Logos en documents - spip - SPIP on GIT qui donnait ça avant Roadmap #3719: Logos en documents - SPIP - SPIP Core (Forge de développement)
Sinon il y a eu ce projet à une époque Liste des chantiers - SPIP mais ça semble à l’abandon comme pas mal de choses :\
C’est évident, pour une 5.0 un minimum transformée, il faut repousser, loin… et compter les forces restantes.
Il serait possible (avec un peu de motivation) de proposer une 4.3 à la place (en partant de la 4.2).
Cette version n’aurait rien de transcendant, juste quelques petits changements…
{having}, et {collate}, {groupby}, avec dépréciation des anciens nomsextraire_balise et extraire_balises peuvent gérer des balises imbriquéesEt certainement d’autres petites choses que je n’ai pas en tête…
À réfléchir ?
Claro, je propose qu’on décale la date d’un an, je prépare une PR en ce sens.
Ok pour moi, ainsi on ne change pas les dates de support pour la 4.1 et la 4.2 si cette 4.3 est prête pour le 24 janvier.
Voilà, je propose de décaler la 5.0 d’un an et de publier la 4.3 le 24 février 2024 (pour nous laisser du temps) cf chore(roadmap): update dates (!24) · Merge requests · James / supported-versions · GitLab
Bonjour,
Plutôt que de faire une 4.3 qui amènerait à devoir changer les bornes de compatibilité de moultes plugins, est-ce qu’une 4.2.50 ne serait pas plus logistiquement envisageable ?
Avec maintenance de la branche 4.2.0-49 et de la branche 4.2.50-99 ?
Je sais bien que ça n’est pas très SemVer.
Mais, là aussi, les forces restantes…
Ou alors, corriger SVP en 4.3 pour que tout en autorisant les plugins 4.2, il charge les plugins pour 4.3 si disponibles…
Non !
Mais non plus…
Je précise que les plugins peuvent déclarer une compatibilité max avec une étoile, et dire ainsi qu’ils sont compatibles SPIP 4.* ce qui, si on arrive (ce qu’on tente) à respecter une compatibilité correcte (ie: à peu près semver), ne devrait pas poser de souci particulier. Ce qui correspond à ^4 ou ^4.0 dans le monde des dépendances Composer… et dire donc [4.1;4.*] devrait pouvoir dire à partir de 4.1 tout en restant dans la branche 4.
Oui, sauf que l’immense majorité ont actuellement une borne 4.2.*
Et qu’une 4.3 sans réelle rupture de compat va pourtant, de fait, quand même en introduire une (incompatibilité) chez plein de gens.
Je sais, c’est pas simple… 
Je pense que c’est justement le bon moment de modifier les bornes de compatibilité des plugins de 4.2.* en 4.*
Yep, je le conçois.
Tu as une proposition de ce qui pourrait être fait ?
Ou on repousse tout simplement ?
Le 19/12/2023 à 10:29, Matthieu Marcillaud via Discuter de SPIP a écrit :
Yep, je le conçois.
Tu as une proposition de ce qui pourrait être fait ?
Ou on repousse tout simplement ?
Est-ce qu’on part du principe qu’à partir de maintenant, toutes les versions X.* ne cassent réellement rien de grave, rien d’important ? Il faut répondre « fermement » à cette question, car il me semble de mémoire qu’il y a eu quelques modifs quand même cassantes en 4.0 et 4.1, ou entre 4.1 et 4.2 je sais plus trop (d’API ou suite à des changements de compat PHP qui obligeaient à certaines modifs obligatoires pour pas que ça pète).
SI jamais la réponse est positive à partir de la 4.2 (et pour l’infini et au-delà), alors on pourrait communiquer officiellement et clairement là-dessus, et dire que majoritairement, la plupart des plugins peuvent désormais configurer une compat supérieure de 4.* dès maintenant (et plus tard dans la branche suivante pour 5.* dès le départ quand ça sortira si on continue de bien suivre le même principe), chose qu’on n’a jamais jamais faite depuis des années, on a toujours dit/montré l’exemple de mettre X.Y.* dans la borne supérieure.
Communication à faire un peu/assez en amont de la sortie de 4.3, pour que tout le monde ait le temps de changer la majorité des plugins en 4.*.
Et ensuite ça roule ?
–
RastaPopoulos
Hé les gars vous pourriez bosser un peu pour releaser une version, mais svp changez pas le numéro qu’on ait pas à vérifier que nos plugins sont compatibles et qu’on puisse mettre tout à jour les yeux fermés hein, parce que nous on voudrait pas avoir trop de travail…
Ho Ho Ho ! Joyeux Noël
Autrement posé : serait ce t il pas raisonnable, justifié et plus fluide de considérer que les plugins compat 4.1 et 4.2 sont compat 4.* et corriger au moment où ils sont détectés, si jamais il y en a, les éventuels problèmes de compat à l’intérieur d’une même 4.* , plutôt que de faire « comme si » il y avait systématiquement des problèmes de compatibilité et forcer plugin par plugin à dire qu’il n’y en a pas ?
Le 19/12/2023 à 11:12, cerdic via Discuter de SPIP a écrit :
Hé les gars vous pourriez bosser un peu pour releaser une version, mais svp changez pas le numéro qu’on ait pas à vérifier que nos plugins sont compatibles et qu’on puisse mettre tout à jour les yeux fermés hein, parce que nous on voudrait pas avoir trop de travail…Ho Ho Ho ! Joyeux Noël
Commentaire ironique qui évince l’expérience réelle des trois dernières années : il y a eu des mois et des mois de décalages entre les sorties des versions SPIP, et les compatibilités des plugins. Ce qui a occasionné des complications et des retards de mises à jour pour de nombreux sites tenus par des non-devs (je ne parle donc clairement pas des sites maintenus par des prestataires mais ça vaut parfaitement aussi quand ce sont des petites structures asso etc qui n’ont pas l’argent pour payer des màj plus longues que de raison s’il faut tester plein de compats).
La comparaison de marcimat avec composer où il est quand même courant de voir des compats X.* (^X chez eux) est intéressante. D’où la question parfaitement légitime et pertinente de savoir si on peut affirmer que désormais on suit mieux les semvers qu’avant, et que désormais il n’y aura plus (ou très très rarement) de cassures importantes à l’intérieur d’une même branche X (mais attention ça vaut pour la compat PHP qui parfois oblige à des modifs cassantes). Ce qui permettrait effectivement de mettre les plugins en X.* supérieur (chose qu’on n’a jamais fait pour l’instant), et les faire tenir plus longtemps, sans tests et maintenances trop rapprochés.
–
RastaPopoulos