Project

General

Profile

Evolution #4798

Suppression des mises à jour de BDD < SPIP 3.0 (ou 3.1 ?)

Added by marcimat 🌻 26 days ago. Updated 19 days ago.

Status:
Fermé
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
05/25/2021
Due date:
% Done:

0%

Resolution:
fixed

Description

Je propose pour continuer dans les nettoyages de SPIP 4.0 de supprimer tous les ecrire/maj/ qui concernent des versions de SPIP antérieures à SPIP 3.0 (voire SPIP 3.1 ?)

La suggestion est de dire : pour mettre à jour votre SPIP,

  • passez d'abord en 3.2 (LTS) s'il n'y est pas. (Du coup on peut mettre un PHP récent)
  • puis migrez en 4.0

Dès lors, et ça permettrait, en plus de nettoyer, d'enlever d'autres deprecated tel que upgrade_vers() ou maj_version(), car leur usages disparaitrait.

Concrètement ça veut dire :

Suppression de :

  • ecrire/maj/legacy/v*.php
  • SPLIT de maj/legacy/svn10000.php
    • suppression du code < 3.0.0 dedans, soit < à la révision svn 19428 ~ . 19428 (3.0.0), 22704 (3.1.0), 23778 (3.2.0)
    • séparation en fichiers maj/legacy/30.php 31.php, 32.php ? (ou pas)

Qu'en pensez vous ?

Ça voudrait dire que les migrations vers SPIP 4.0 fonctionneraient à partir d'un site SPIP 3.0 ou 3.1 (selon ce qu'on choisit) minimum.

History

#1 Updated by b b 26 days ago

Autant ça me chagrine un peu car je trouve vraiment confort et formidable de pouvoir up un vieux site en 2.0 ou 2.1 vers la dernière branche stable les yeux (presque) fermés, mais je rejoins l'argument du nettoyage, donc +1.

Si la première étape est bien "passez d'abord en 3.2", pourquoi garder le code d'upgrade qui concerne 3.0 et 3.1, on peut s'en passer si les gens sont bien en 3.2 avant le passage en 4.0, non ?

#2 Updated by marcimat 🌻 26 days ago

L'autre solution… bien plus conséquente à faire … serait de migrer toutes les vieilles mises à jour dans le formalisme à jour. (par exemple rangé par version de SPIP legacy/x.y.php)
Ça éviterait aux fonctions deprecated d'être utilisées.

L'argument très recevable de Cédric aussi est de dire : si tu pars d'une vieille bdd, installée sur ton SPIP 4.0 (mysql ma_bdd_spip4_vide < mon_vieux_spip.sql), alors SPIP met à jour (bon, ça gère pas tout à la perfection non plus).

Mais bon, maintenir les vieilles migrations nécessite de maintenir aussi probablement des vieilles fonctions totalement inutiles actuellement, même si on les passe dans un formalisme plus actuel.

Quand à 3.0, 3.1 ou 3.2… bah en fait comme on veux (juste que c'est le nouveau formalisme de mises à jour à partir de la 2.0), donc ce qui m'ennuie là est surtout ce qu'il y a avant la 2.0 il me semble.
On pourrait aussi possiblement dire 2.0 comme départ je crois.

#3 Updated by nicod _ 26 days ago

b b a écrit :

Autant ça me chagrine un peu car je trouve vraiment confort et formidable de pouvoir up un vieux site en 2.0 ou 2.1 vers la dernière branche stable les yeux (presque) fermés, mais je rejoins l'argument du nettoyage, donc +1.

Tout pareil, j'ai toujours trouvé formidablement chouette de pouvoir migrer un site qui a plus de 15 ans en quelques minutes sans (quasi) aucun effort, c'est assez unique et magique.
Donc ça provoquerait une "rupture" historique, mais ça n'arrive pas tous les jours non plus et je comprends aussi l'objectif du nettoyage.

Donc, tant que c'est bien documenté officiellement, +1

#4 Updated by marcimat 🌻 26 days ago

D'après https://core.spip.net/projects/spip/wiki/WikiStart#Anciennes-versions

Et le fait que le premier numéro de https://git.spip.net/spip/spip/src/branch/master/ecrire/maj/legacy/svn10000.php est le 10990 (1.9.2d = 11132), on pourrait conserver pour la 4.0 la migration probablement depuis 1.9.2d. Sans que ça soit très gênant pour le moment.

Mais même, le fichier maj/v019.php a la nouvelle écriture, et commence en 1931 (1.7.0 = 2414)...
On pourrait même conserver depuis 1.7.0.

Mais le veut-on vraiment ?
On peut conserver «à partir de 2.0.0» (13469), pourquoi pas ? ou toute version au dessus…
Ou à partir de 1.9.2 ou 1.8… ou je ne sais pas…

Bref… pour moi tant qu'on vire les maj/vxxx.php antérieurs à l'ancien formalisme, déjà ça me va.

Mais indépendamment de ça, conserver ad-vitam les trucs, ça a pas forcément trop de sens quand même.

#5 Updated by nicod _ 26 days ago

Mais indépendamment de ça, conserver ad-vitam les trucs, ça a pas forcément trop de sens quand même.

Oui oui, sur une telle plage de temps (20 ans !), à un moment il peut y avoir une rupture causée par une évolution technique, c'est tout à fait compréhensible.
C'est déjà merveilleux que les mises à jour soient si faciles.
Donc faisons au mieux pour ne pas compliquer la maintenance (i.e. nettoyons effectivement ce qui doit l'être), tant que la possibilité d'upgrade n'est pas bloquée et documentée (très vieux site -> 3.2, puis 3.2 -> 4.0).
Je croise encore de temps en temps des SPIP 2 à mettre à jour, mais des 1.x plus du tout.
Si «à partir de 2.0.0» n'est pas gênant, pourquoi pas ?

#6 Updated by cedric - 26 days ago

Ça me semble un bon compromis de conserver la maj depuis 3.0+, ça permets de migrer un SPIP en 3.x quelle qu'elle soit vers une 4.0, et c'est plus souple aussi pour la montée de version depuis une version antérieure à 3.X : il suffit d'upgrader en n'importe quelle 3.x qui fonctionne sur le serveur puis en 4.x.

Par ailleurs, sur le papier oui on est capable de migrer une base depuis une 1.x même vers une 4.0, mais en pratique personne ne le vérifie, il est pas du tout impossible que certaines mises à jour plante parce que depuis la fonction support a un peu changé de comportement. Donc c'est une capacité assez théorique sur une telle plage de temps, et je crois que le dernier qui a essayé de migrer depuis une très vieille version s'est plaint que ça ne marchait pas... cf #4591

#7 Updated by marcimat 🌻 19 days ago

  • Status changed from Nouveau to Fermé
  • Resolution set to fixed

Ah mais c'est fait au fait.
https://git.spip.net/spip/spip/pulls/191

Et donc on a enlevé tout ce qui est < 2.0.0.

Also available in: Atom PDF