Hello,
Suite à quelques échanges et un petit ménage dans les tickets de SPIP, nous tentons d’utiliser plus activement la fonctionnalité des jalons gitlab (ou milestones) pour la maintenance de SPIP.
L’objectif recherché est d’améliorer la prise en compte de ces tickets (issues), de les « qualifier », de les associer à une version de SPIP, afin de ne pas en oublier en route et de donner de la visibilité sur le moment où la demande sera intégrée dans une version installable, même si cela restera une estimation et dépendra essentiellement du nombre de personnes impliquées et de leur « capacité à faire ».
Infos importantes
- Nous prévoyons de sortir une version 4.3.0 au début du mois de juillet 2024 (dans moins de 3 mois)
- Nous prévoyons de sortir une version 4.4.0 en début d’année 2025, en même temps que la version 5.0 de SPIP. Cette version sera en
LTS(long term support) le moment venu. Cela signifie que la durée de sa maintenance sera plus longue que les versions mineures qui la précèdent. - Les plugins-dist (distribué dans le zip de SPIP qui sert à la mise à jour) ont désormais une compatibililté « à étoile ». C’est à dire que, dans la notation des
paquet.xml, l’attributcompatibilitede la balise<paquet>a pour valeur[4.2.0;4.*]. Ainsi, ils sont considérés a priori compatibles avec les futures versions mineures de SPIP4. Le noyau de SPIP devra donc rester retro-compatible depuis la 4.2 jusqu’à la 4.4
Je remets ici le petit tableau qui propose les changements :
Dates, durées, nombres de versions mineures sont toujours en discussion… non définitives, non officielles encore. Ce n’est pas graavé dans le marbre, c’est une illustration du modèle proposé ! 
Quelques explications ci-dessous :
Milestones (ou jalons)
Elles sont accessibles sur la plate-forme GIT, dans le projet spip/spip
J’y ai mis des dates prévisionnelles et une description (ex: SPIP4.2 qui précise dans quelle phase de maintenance la version se trouve et un tableau de rappel des passages d’une phase à l’autre.
Ces dates sont actuellement proposées, elles sont à discuter, l’idée étant de trouver un juste équilibre entre un certain automatisme, une adaptation au moment présent, …
Chaque millestone représente une version mineure (X.Y) de SPIP. Nous avons d’ailleurs déplacé (ou fermé) les tickets associés à un jalon historique « 99 - à plus tard » et supprimer le jalon. Un nouveau ticket sera donc à sa création sans milestone, un groupe de personnes évaluera la demande et affectera la milestone (donc, version de SPIP) pour laquelle il sera(it) possible de traiter la demande.
Cycle de vie des versions
Chaque version, majeure (X) , mineure (X.Y) aurait un cycle de vie un peu plus visible qu’aujourd’hui. Je passe sur les détails techniques, mais les informations de milestones sont exploitables via l’API GitLab pour être restituées et mises en forme dans le futur sur des pages comme celles des versions maintenues, par exemple.
Ainsi, les « phases » sont les suivantes (rien de nouveau ici, nous essayons de suivre ce modèle depuis quelques années) :
- développement (dev)
- maintenance active (bugfix essentiellement)
- correctifs de sécu (security-fix)
- fin de vie (eol)
Voir la légende des versions maintenues
Ainsi, à ce jour :
-
3.2et4.0sont en fin de vie (milestones closes) -
4.1en security-fix -
4.2en bugfix -
4.3et5.0en dev
Si le modèle convient, il serait possible de prévoir dès aujourd’hui les milestones 4.4 et 5.1 par exemple…
Branches GIT
Historiquement, nous créons une branche de maintenance (bugfix->eol) lors de la sortie d’une nouvelle version « stable », master devenant la prochaine version en développement.
Le renommage de master en autre chose peut redevenir un sujet d’actualité… mais reste la branche par défaut du projet spip/spip, et donc celle ou se développe une future version.
Toutefois, nous allons créer dans la soirée la branche 4.3, à partir de la branche 4.2 afin de démarrer les dev nécessaires pour embarquer les améliorations/évolutions à lui apporter avant sa release en juillet. Exceptionnellement donc, nous aurons 2 branches de développement et ceci ne devrait se produire qu’une seule fois, si tout va bien …
Là encore, je passe les détails, mais il serait techniquement possible de supprimer les branches 3.2, 4.0 etc, les commits n’étant eux, pas supprimés et les tags du type « 3.2.z » toujours présents. Nous n’y toucherons pas pour l’instant…
Les releases de patch (X.Y.Z), mensuels, sont toujours d’actualité.
Compatibilité des plugins
Pour que les plugins communautaires bénéficient de la compatiblité automatique avec les futures versions 4.x, il suffira de mettre à jour l’attribut compatibilite du paquet.xml. Là, à voir s’il y a besoin d’organiser des choses, ou de laisser faire les mainteneureuses …
Conséquences sur les tickets non-traités actuels
Il reste environ 55 tickets de ‹ bugs › sur la 4.2 :
Tout ce qui serait traité d’ici au 1er juillet 2024 serait ‹ corrigé › dans une 4.2.12, 4.2.13 ou 4.2.14.
Les bugs non traités basculeraient alors, assez logiquement, dans la 4.3
Il y a presque 300 autres tickets dont certains sont déjà affectés à une version « future ». Reste à saavoir laquelle et à voir comment, collectivement, on les dispatche.
–
James, pour l’équipe @maintenance