Je rencontre un soucis actuellement avec la branche 2.1, une évolution
introduite sur la 2.1.29 empêchent de mettre à jour dans un contexte
particulier. En l'occurence, le connecteur mysqli introduit dans la
2.1.29. (qui n'est pas dispo sur l'hébergement surlequel je n'ai pas
la main, certes c'est assez rare de nos jours d'avoir un php sans
mysqli). C'est un problème personnel, mais peut-être que d'autres le
rencontre ? (ex http://forum.spip.net/fr_264727.html)
Je me demande si les évolutions dernièrement introduites qui devraient
se retrouver dans la 2.1.30 (j'ai survolé quelques commits qui ne
paraissent pas toujours anodins) n'auraient pas plus leur place dans
une branche 2.2, et la branche 2.1 n'aurait alors que des patchs de
sécurité afin de permettre aux sites qui n'ont pas forcement besoin de
ces évolutions d'être maintenu simplement par une montée en version
mineure.
Les autres pourront tester les évolutions avec une 2.2 qui serait
alors bienvenue.
Qu'en pensez-vous ?
Je rencontre un soucis actuellement avec la branche 2.1, une évolution
introduite sur la 2.1.29 empêchent de mettre à jour dans un contexte
particulier. En l'occurence, le connecteur mysqli
(…)
Je me demande si les évolutions dernièrement introduites qui devraient
se retrouver dans la 2.1.30 (j'ai survolé quelques commits qui ne
paraissent pas toujours anodins) n'auraient pas plus leur place dans
une branche 2.2,
Mysqli est la seule interface Mysql disponible dans PHP7 et a été introduite en PHP 5.0,
les versions antérieures de PHP n’étant plus maintenues depuis des années.
De mon point de vue SPIP ne devrait pas se soucier d’être compatible avec des versions non maintenues de PHP.
Depuis que j’ai découvert un hébergeur qui fait payer des suppléments pour qui veut en utiliser une,
j’en suis encore plus convaincu. Partant, annoncer un SPIP 2.2 implique de déclarer que SPIP 2.1 n’est plus maintenu.
Est-ce un meilleur signal à envoyer que de déclarer que la 2.1 est compatible PHP7 au prix de l’incompatibilité avec PHP < 5 ?
Ca se discute. Mais ajouté au fait qu’il y a eu une 2.2 jamais sortie mais que certains ont pu récupérer par svn up
il y a qq années, je pense qu’il vaut mieux rester sous le nom 2.1.
De mon point de vue SPIP ne devrait pas se soucier d’être compatible avec des versions non maintenues de PHP.
Le simple fait qu'un utilisateur rapporte un problème lié à cette rupture de compatibilité montre que tu es sans doute trop optimiste.
Partant, annoncer un SPIP 2.2 implique de déclarer que SPIP 2.1 n’est plus maintenu.
Est-ce un meilleur signal à envoyer que de déclarer que la 2.1 est compatible PHP7 au prix de l’incompatibilité avec PHP < 5 ?
Sur le fond, je trouve anormal de rompre une compatibilité, quelle qu'elle soit, sans même changer le n° de sous-version.
La version 2.1 ayant été introduite sans nécessiter mysqli, elle devrait continuer de même. Si on considère que cette contrainte est liée à un environnement obsolète, alors la (sous-)version est également obsolète et on crée une version modernisée. Quand je vois le nombre de versions 1.9 encore actives, je n'ose imaginer ce qui se passerait si on leur avait supprimé leurs anciennes compatibilités...
D’après mes tests c’est ok finalement. Cela dit mon souci premier est d’éviter le numéro 2.2 pour les raisons que j’ai dites.
Mais si on sort un nouveau numéro dans la série 2, il faut peut-être penser à un peu plus que le seul pb de la compatibilité PHP7.
Par exemple le fait de devoir écrire à la fois un plugin.xml et un paquet.xml pour ses plugins est vraiment dommage, surtout quand on sait que la lecture des « paquet.xml » faisait justement partie de la 2.2 jamais sortie. Ce n’est qu’un exemple.
Je vais poser une question idiote, mais n'y aurait pas possibilité de
faire en sorte de passer à une 3.truc ?
En lisant les remarques précédentes, j'ai l'impression que c'est
essayer de reporter en 2.x ce qui existe en 3.x.
Ne serait il pas pertinent de voir pour permettre à la 3.x d'avoir une
meilleure rétrocompatibilité ? Peut être via un module "vieillerie" ?
J'ai du mal à comprendre les situations qui justifient de devoir
rester en 2.x . Pour le moment j'ai compris le "problème de la
migration/montée de version" mais j'ai l'impression que le travail
pour maintenir le système est plus coûteux que faire les correctifs
pour la migration. Ce qui accentue mon incompréhension, c'est que je
n'ai pas encore rencontré de cas imposant de rester en 2.x