Si vous avez vu le petit tableau qui propose l’utilisation des milestones, vous avez constaté qu’il y a un truc qui change dans la manière de sortir des versions majeures et mineures à partir de SPIP5.
L’idée est la suivante :
La communauté maintient 2 versions à un même moment (ce qu’on fait, en gros, depuis la 3.2, en 2017)
Elle publie des patches (X.Y.Z) des versions maintenues (les releases mensuelles) une fois par mois, modulo le status (bugfix, security-fix)
Elle « développe » la version suivante.
Et maintenant, elle proposerait de publier des mineures à intervalles réguliers, dans le but d’intégrer des améliorations/évolutions/nouveautés tout en suivant les versions de PHP (qui sortent une fois par an). À cela s’ajoute, le souhait de réduire la charge de la maintenance en utilisant du code venu et maintenu ailleurs. Ce souhait, aujourd’hui, cible essentiellement l’utilisation des composants du framework symfony, voire de transformer SPIP en application Symfony… qui publie selon un rythme régulier, plus « rapide » que PHP: une mineure tous les 6 mois environ.
C’est ce qui est donc proposé pour SPIP aujourd’hui : sortir des mineures régulièrement tout en conservant ce que la commu fait aujourd’hui.
Pour cela, j’ai choisi arbitrairement, pour illustrer ça, des durées de vie et un nombre de versions mineures par version majeure. à savoir 1 mineure par an et 5 (de 0 à 4) mineures par majeure.
La question maintenant est : Est-ce que c’est vraiment ça qu’on fait ?
On pourrait dire, pourquoi pas 6 mois, pourquoi pas 9 mois, pourquoi pas 3 mineures au lieu de 5 ?
C’est un peu cette équation que je propose de résoudre.
On voit bien qu’il est très difficile de satisfaire tout le monde.
Je suis évidemment favorable à ce que tu proposes, mais il faut aussi réussir à fluidifier encore la création de releases. Là ça va fonctionner tant que 3 personnes (en gros) sont toujours suffisamment motivées à ça (s’occuper des branches, changelog, reports & adaptations, et faire les releases…) ; je te cache pas que ça prend du temps (pas mal même ce début de passage à 4.3), et que c’est aussi du temps qui n’est pas utilisé à faire avancer la transformation de la 5.0.
Cela dit j’ai espoir que ça puisse améliorer la motivation des participant·es qui peuvent continuer d’apporter des améliorations dans la branche 4.x du coup, et qu’on peut peut être aussi faire des reports qui faciliteraient le passage à SPIP 5 (tu me parlais en PV de mettre les composer.json des plugins-dist par exemple dans la 4.3, qui serait une petite étape de franchie)
Comme je l’ai dit maintes fois, ça me va bien des versions Y tous les 6 mois, même si elles n’ont pas de super feature de la mort qui tue dedans, à partir du moment où on n’a pas à recréer autant de branches sur les plugins-dist à chaque fois (là j’ai tout passé par défaut en borne max 4.*, ce qui devrait éviter cela donc).
Mais comme ça dépend beaucoup de la motivation fluctuante de qq personnes, je crois qu’il faut réussir à dire que c’est une projection, un souhait, et que… peut être que ça évoluera encore.
Il faut qu’on arrive à garder de la joie à participer, tout en transformant assez radicalement la base structurelle du code de SPIP !
Ok pour dire que c’est un souhait, une projection, sinon.
→ Qu’est-ce qu’on essaye ?
la compat’ à étoiles, ça va aider, c’est sûr.
peut-être aussi qu’il serait intéressant de voir comment on gère les cycles de vie des plugins-dist. 2 possibilités me viennent à l’esprit, il y a en peut-être d’autres :
Certains composants de Symfony suivent le même rythme. Ils sont tous versionnés en même temps, avec les mêmes valeurs. Tandis que d’autres ont leur vie propre …
Coté SPIP, on pourrait dire, mêmes milestones (on promeut les milestones spip/spip au niveau de l’orga spip), mêmes branches, mêmes tags pour SPIP et les plugins-dist, qu’il y ait du changement ou pas.
Les outils de releases pourraient systématiser ça, je pense.
Chaque plugin-dist à son cycle de vie qui lui est propre. On décorrèle au mieux la dépendance de ces plugins à l’API de SPIP.
Ainsi, on n’est plus obligé de taguer des plugins-dist quand ce n’est pas nécessaire
Une version d’un plugin-dist, tant qu’elle est compatible avec les versions min/max de PHP peut étendre sa compat’ SPIP (ex: [4.2.0;5.*] … ). Un peu comme d’autres plugins, en somme.
Vu qu’on a déjà le 4.* sur les plugins-dist de la 4.3, on pourrait je pense aller vers cette option si ça ne nous complique pas la tâche (je pense même que ça la faciliterait).
Sinon, le solstice semble plaire et si c’est plus proche de ce qu’on a déjà fait, ça me va aussi.
Security support for major PHP versions has increased by one year. The lifespan of each PHP version will be 4 years: 2 years of bug fixes and 2 years of security fixes. The changes apply immediately to all currently supported branches, and the PHP 8.1 branch will receive an additional year of security fixes.
moi je m’interroge sur le « c’est quoi la 5.0 ». Autrement dit: a-t-on besoin que tout soit composerisé pour sortir une 5.0 ? ne peut pas mettre des choses deja compsorisé dans les 4.y ?
,
