Cela fait suite à différentes discussions sur le cycle de release de SPIP.
Notre objectif (si on y arrive) est d'avoir des releases plus fréquentes (au minimum une fois par autour du moins de décembre — soit peu après la sortie d'une nouvelle version de PHP).
Les versions majeures de SPIP seront compatibles avec les versions maintenues de PHP au moment de leur sortie.
Soit à ce jour de PHP 7.3 à 8.0
dans SPIP, c’est à dire avec une mise à jour de la date à chaque update.
On migre les champs des tables connues.
Cependant, sur les tables crées auparavant avec une version de mysql récente, la colonne avec TIMESTAMP accepte les valeurs NULL et les accepte et en contient toujours après cette migration.
Il faudrait peut être une autre migration pour appliquer une valeur sur tous les NULL pour pouvoir enlever cette indication dans la déclarationd du champ que nous n’avions pas auparavant.
Autrement dit, on obtient 'TIMESTAMP NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP' à la place de 'TIMESTAMP default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP'.
Mais ça ne doit pas être très gênant.
A noter : le core migre les logos de tous les objets connus au moment de l'upgrade, mais si un plugin se desactive car pas compatible, ses logos ne seront pas migres. Il y a donc une fonction generique logo_migrer_en_base() generique que chaque plugin sera avise d'ajouter a ses upgrades pour SPIP 3.3
(au passage on supprime le hack sur la globale formats_logos qui consistait a avoir la position de l'extension correspondant a la valeur IMAGETYPE_XXX retournee par getimagesize() et on passe le gif en dernier pour des raisons de performance car c'est le format le moins utilise maintenant)
Déclarons les explicitement. Cela évite de nombreux soucis, notamment lorsqu’on charge
ce fichier pour démarrer SPIP depuis une fonction en CLI.
Ça évitera à SPIP-Cli ou d’autres outils de devoir les déclarer en amont;
r22712 indiquait que la constante _DEV_VERSION_SPIP_COMPAT est définie à la dernière version stable pendant la phase de dev du trunk, mais on risque certainement d'oublier de la mettre à jour à chaque release stable, donc autant la définir avec un y de version à 99 (* n'étant pas pris en compte ici)
marcimat@rezo.net
