Hello,
Un mois après le premier CR Maintenance, voici le deuxième.
Sortie de SPIP 4.2.12 & 4.3.0-alpha
Quelques personnes de l’équipe ont travaillé dur pour pour sortir ces nouvelles versions. La revue et l’intégration des PRs, leur reports puis la release en elle-même ont nécessité une journée quasi complète de travail. Merci à elles !
Rappel de vocabulaire
SPIP suit une numérotation de version en x.y.z.
- Un changement de X (ex 4.2 → à 5.0) est une mise à jour majeure
- Un changement de Y (ex 4.2 → 4.3) est une mise à jour mineure
- Un changement de Z (ex 4.2.11 → 4.2.12) est une mise à jour corrective, qui peut contenir des corrections de bugs (bugfix) ou de failles de sécurité (security-fix)
Infos importantes
Officialisation de la roadmap (feuille de route) proposée le mois dernier
- Les releases mensuelles se poursuivent avec la version
4.2.13début juin et une4.2.14courant juillet 2024. - Après la sortie de
SPIP 4.3.0-alpha, nous publierons une beta courant juin avec, si possible, une période de « code freeze » d’un mois afin de publier la version stable4.3.0stable courant juillet 2024. - La version
4.4 LTSest confirmée pour janvier 2025. - Nous prévoyons de mettre en place un cycle de vie régulier à partir de la
5.0prévue pour janvier 2025.
Voir le calendrier ci-dessous :
Que vous trouverez toujours à l’adresse : https://www.spip.net/fr_article6500.html
Stats à l’instant t des tickets par milestones (jalons)
| Milestone | Complétion | Notes |
|---|---|---|
| 4.1 | 100% | Fin de vie fin janvier 2025 (exceptionnellement) |
| 4.2 | 76% | security-fix courant juillet 2024 |
| 4.3 | 56% | stable courant juillet 2024 |
| 4.4 | - | stable fin janvier 2025 ( ) |
| 5.0 | 24% | stable fin janvier 2025 () |
La complétion correspond au pourcentage de tickets clos par rapport au nombre total de tickets associés à la milestone.
Pour suivre à tout instant l’avancement via les milestones de spip/spip : https://git.spip.net/spip/spip/-/milestones
Code freeze
Dans la mesure du possible, afin de mieux préparer la sortie de la version 4.3.0 « stable » de juillet, nous envisageons un « code freeze » lors de la sortie de la 4.3.0-beta courant juin.
Cela signifie que nous souhaitons concentrer nos efforts pendant 1 mois sur la stabibilisation de la version et ne plus introduire de nouveautés ou d’améliorations dans cette branche (4.3).
Le développement de la 4.4 pourrait alors débuter avec des améliorations qui n’auraient pas eu le temps d’être intégrées dans la 4.3.
LTS
LTS pour Long Term Support. Autrement dit, pour une durée maintenance étendue dans le temps en terme de correctifs de sécurité.
SPIP 4.4 LTS sera donc maintenue jusqu’en juillet 2027. Son support devrait se dérouler de la manière suivante:
- une période de
bugfixde 6 mois jusqu’en juillet 2025, - suivie d’une période de
security-fixde 2 ans et demi, jusqu’à la sortie de la version LTS suivante. -
eol(fin de vie, sans nouvelle mise à jour) après la sortie de SPIP5.4 LTS.
Comment ça va se passer à partir de 5.0 ?
Nous allons faire en sorte de sortir une version mineure de SPIP 5 tous les 6 mois.
Comme dit plus haut, avec SPIP 5.0 en janvier 2025, 5.1 en juillet 2025, … jusqu’à la 5.4 LTS en janvier 2027.
Chacune de ses versions mineures aura une durée de support/maintenance raccourcie à 6 mois : dès qu’une version mineure sera publiée, la précédente ne sera plus maintenue, à l’exception de la dernière, la 5.4 qui sera en LTS.
Ceci devrait nous permettre de publier des versions avec des nouveautés plus régulièrement et de mettre en place des chantiers plus structurants.
Il y aura donc 2 choix possibles pour les mise à jour de SPIP à partir de ce moment.
Early adopters (Adeptes de la nouveauté)
Il sera possible de faire la mise à jour de vos sites à chaque version mineure, tous les 6 mois.
Régime stable
Il sera possible de faire des mises à jour des versions majeures entre chaque version LTS, tous les 3 ans.
Dans tous les cas
- Si vous utilisez une version end of life (eol), il vous faut faire une mise à jour majeure
- Si vous utilisez une version bug fix ou securite fix, il vous faut faire les mises à jour de sécurité, il est recommandé de faire les mises à jour de correctif, il est encouragé de faire les mise à jour mineures
Conséquence sur les plugins communautaires
Afin d’adopter plus rapidement les versions qui seront publiées dans le futur, nous proposons de modifier les bornes de compatibilités de SPIP des plugins communautaires par anticipation, comme nous l’avons fait pour les « plugins-dist ».
L’idée est ici de faire en sorte que pour un plugin compatible avec SPIP4.2, il est d’ores et déjà compatible avec SPIP4.3 et SPIP4.4.
L’adoption d’un régime de versionnement sémantique doit permettre d’éviter des ruptures de compatibilité.
Solution
Modifier les bornes de compatibilité SPIP du fichier paquet.xml de la manière suivante :
-<paquet compatibilite="[x.y.z;4.2.*]" ...>
+<paquet compatibilite="[x.y.z;4.*]" ...>
Pour que le plugin soit ensuite accessible au plus grand nombre, il faut suivre la démarche de release standard :
- modification du numéro de version du plugin
- le cas échéant, modification du changelog
- pose d’un tag (afin que la nouvelle version soit disponible via SVP)
Quelques éléments
| Groupe | Projets | paquet.xml |
Compatibilité 4.2.*
|
Compatibilité 4.* ou plus |
|---|---|---|---|---|
| spip | 40 | 31 | 6 | 23 |
| spip-contrib-extensions | 945 | 893 | 459 | 19 |
| spip-contrib-squelettes | 185 | 98 | 45 | 2 |
| spip-contrib-themes | 169 | 47 | 29 | 9 |
| spip-contrib-outils | 23 | 0 | N/A | N/A |
| spip-galaxie | 21 | 11 | 4 | 1 |
Légende:
- Groupe: le groupe git dans lequel les dépôts git sont répartis
- Projets: le nombre de dépôts git publics et non-archivés
-
paquet.xml: le nombre de dépôts dans lequel on trouve un fichierpaquet.xmlà la racine dans sa branche par défaut (ce qui en fait un plugin SPIP…) - Compatibilité
4.2.*: le nombre de plugins compatible SPIP4.2 (borne max de l’attributcompatibilite) - Compatibilité
4.*ou plus: le nombre de plugins pour lesquels la modification a déjà été faite
Labels pour les issues et les PRS
Nous avons mis en place des « labels de groupe » sur la plate-forme GitLab.
Ils sont communs à spip et à spip-contrib-extensions. Des explications détaillées seront fournies plus tard.
Ceci est applicable aux autres groupes existants (outils, squelettes, themes, galaxie, graphismes, …).
Il est possible de traiter en masse ces groupes, comme cela a été fait pour les groupes spip et spip-contrib-extensions.
La suite ?
- Nous préparons SPIP 4.3
- Un ménage technique concernant les plugins-dist est en cours (milestones, branches, transfert)
Prochain CR Maintenance le 17 juin 2024.
Questions ouvertes
Il est possible de traiter en masse les plugins compatibles 4.2.* pour les marquer comme compatible 4.*.
- Soit en créant une branche, une PR et d’attendre un certain nombre d’approbations avant le merge,
- Soit en poussant directement la modification dans la branche par défaut.
- Faut-il le faire ?
- Si oui sous quelle forme : PR ou push direct ?
- Quelle part des mainteneureuses pour le travail finale de modification du numéro de plugin et de pose des tags ?
–
@b_b, @tofulm, @maieul et James, pour l’équipe @maintenance
